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FOREWORD 


This collection of papers and resources on aerospace management is an outgrowth of 
recommendations issued in 1986 by the NASA Management Study Croup, better 
the Phillips Committee. A key recommendation emphasized 

and development of program and project managers within NASA. A I rogram/Frojeci 
Managlmeriteering Group, established in 1984, set out to develop a management 
experience library to support those formal training and development programs, 
fessonsl-"«i. policy, tools and development information. The result is Issues m NASA 

Program and Project Management. 

The statements and opinions of the authors are their own, and do not represent official 
policy of NASA or of the U. S. Government. In fact, some viewpoints m this 
challLge those of other authors, encouraging a diversity of ideas and approaches for NAS 
managers, future managers and NASA alumni. 


A few words about our authors and their offerings: 

Deputy Administrator Dale D. Myer s lends off this puhiication with a 

PrMram Approval Document which served NASA so well in earlier years. He was NASA s 

eiarion Aaron Cohen. Director since 1986 of the Lyndon B. Johnson Space »-enter ^ 
Houston Texas sets the stage with an overview of project management and the evolution 
t?e mriJco“;p^ tL Johnson Space Center culture. He came to Johnson Space 

Center in 1962 and is recognized as one of NASA’s premier director of 

An..lnr.„astaferro . vice president of Lockheed Missiles and 

space station prog7ams at the California corporation, had served '« ^ 

I anori-v Research Center. After promotion as deputy manager of the Viking Project, ne 
s^Tvt7as“; ont planetary" division of NASA’s Omce of Space Sconce and 

ISnTDepu^rAdmtnTsTra^rr'SA^^^^ 

r:;rrrirsrcri9t;:':id^"cr,^t"L^^^^^^^^^ 

R.avond The Atmosphere (1981) from which this article is excerpted. Jack l^ ee ‘s/leputy 
director of the Marshall Space Flight Center in Huntsyiile. Al^ama. 

s;to"r‘idrirarrofM*nT^^^^^^^^ 
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The PAD is Back 

by Dale Myers 

Deputy Administrator of NASA 


NASA has, since its inception, welcomed the 
opportunity to carry out programs and projects. 
Some of these have been technologically and 
managerially challenging, and NASA has evolved 
management processes to assist in the 
documentation and tracking of major program 
milestones and resources utilization. As part of 
these processes, the Program Approval Document 
(PAD) was introduced during the 1960s to record 
the authorization of newly approved agency 
projects. The document, prepared at a summary 
level, outlined the technical plan, number of 
launches, project costs and key milestones for 
management review. The P AD was intended to be a 
contract between the Program Associate 
Administrator and the NASA Administrator on the 
content, schedule, controls and resources of each 
project and was usually updated annually to reflect 
major changes. In the early 1970s, the PAD became 
an even more powerful document, changing from a 
budget orientation to a management one. The 
Administrator began to use the PAD to identify 
items and milestones he deemed critical to the 
orderly progression of the program and to make 
such items Administrator-controlled. In other 
words, once he and the Program Associate 
Administrator agreed to the critical items or 
milestones, they could not be changed without the 
Administrator’s approval. 

The use of the PAD as a management document 
declined in recent years, and the requirement for 
PADs was canceled in 1985. When I assumed the 
Deputy Administrator position, I became aware 
that there was nothing in the system that 
documented program agreements made between 
the Administrator and the Program Associate 
Administrators. I was very concerned that the 


documentation and control which the PAD had 
provided the Administrator no longer existed, and I 
soon began the process to reinstate the PAD. 

First, the new PAD had to be a management 
document. It would indeed be the fundamental 
contract between the Administrator and Program 
Associate Administrator, and it would codify those 
critical items that could not be unilaterally 
changed. 

Second, the PAD would contain significant resource 
information and program milestones that would 
become part of our monthly program and project 
reporting process. 

Third, the PAD would be concise. We do not need 
additional paper in the system. 

Finally, we would apply the PAD requirements 
selectively, not blanket all NASA programs and 
projects with unnecessary documentation. The 
PAD would apply only to those projects the 
Administrator deemed necessary. 


During the past year we have piloted the 
application of the PAD to a number of programs and 
will shortly have 20 or so signed PADs. In the very 
near future we will publish a NASA Management 
Issuance, officially bringing the PAD back. I think 
this is a very positive step in the management and 
control of our programs and projects, since it 
represents the prime objective to be met by the 
Associate Administrators in their area of program 
management. 
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Guiding Principles for the Space 
Station Program 

by James B. Odom 

NASA Associate Administrator for Space Station 


When I came on board in early April 1988, I set 
aside time to reflect on the principles that so far 
have guided my career and would be applicable to 
my new job. I was very comfortable with the 
configuration and management organization of the 
Space Station Freedom program. In the few years of 
its existence, the space station program had 
accomplished much, and becoming part of the next 
logical step in space” would be personally 
gratifying. However, managing a program that 
would spend approximately $20 billion in the next 
10 years would be a real challenge for me. I knew 
that the amount and complexity of hardware and 
the necessary interfaces were beyond anything I 
had worked on, including Apollo, Hubble Space 
Telescope, and the Space Shuttle External Tank 
programs. I concluded that to pull these thousands 
of pieces together and make them fly would demand 
strong leadership at all levels, good communication, 
and some rather innovative ways to define 
accountability, responsibility, and authority. 

Any leader can get bogged down in detail and 
micromanage a program to death. What I needed 
last April were guiding principles, based on lessons 
I had learned, to apply to the challenges awaiting 
me. I’d like to very briefly share these principles 
with you and suggest that, in my experience, better 
decisions and actions result from such clearly 
defined principles. 

1. Mission success is number one . This almost goes 
without saying in NASA. It’s part and parcel of the 
NASA culture. For the Space Station Freedom 
program, however, mission success is not merely a 
single launch or even the final construction of a 
laboratory in space. Rather, Space Station Freedom 
will be multi-purpose, international, and 
evolutionary. It may be three decades before we can 
declare total mission success, and what we do today 
will determine tomorrow’s successes. Mission 


success will be measured by a number of 
parameters; among these are crew safety, research 
capability, ease of maintainability, economy of 
operation and ability to evolve to meet future 
national goals. 

2. Quality is planned in. designed in, and built im 
Quality is not inspected in. Quality starts before 
designs are drawn and well before ”metal is bent.” 
The main message here is that each person and 
organization in the program must understand and 
belieye in the need for quality performance from the 
onset of the program. You cannot wait until the 
hardware is built to decide you want quality and 
then attempt to "inspect” it in. I have often seen 
this tried but never successfully or economically. 

The Technical Management and Information 
Systems (TMIS) will be a significant asset for 
collecting and disseminating information on our 
quality efforts. Quality encompasses more than just 
the delivered hardware. It includes management, 
requirements, design, development, testing, and 
documentation. Simply stated, the quality of every 
person’s output is very important to the outcome of 
the program. 

3. Keep it simple. As engineers we have a tendency 
to make systems more complicated than necessary. 
Our challenge is especially to make flight systems 
simple, thereby increasing reliability, minimizing 
training and crew on-orbit support, and reducing 
development cost. When we succeed, we get the 
added bonus of reducing on-orbit and ground 
logistics support costs. The most expensive 
component in orbit is the one that is not mandatory 
for mission success. 

4. Minimize organizational and hardware 
interfaces, and maximize clear hardware and 
software accountability. An undisputed fact of 
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NASA culture is that our strength resides in our 
field centers. On the surface it may appear that a 
single management team would be preferable to the 
three management levels currently in place. 
However, many of NASA's past successes have had 
multiple field center involvement. Each 
participating field center brings much added value 
to the program by the center management review 
process and the personnel and facilities which could 
not be duplicated at any single NASA installation 
or prime contractor's facility. We have established 
a clear requirements chain-of-accountability by 
having the appropriate requirements derived, 
controlled, and accounted for at the appropriate 
management level, In doing this we have placed 
the top level program responsibilities at 
Headquarters (Level I and II) and taken maximum 
advantage of the field centers’ management and 
engineering expertise in design, development, 
manufacturing, and operations. Now, to further 
ensure that the program is fully integrated at the 
field centers and prime contractors, we have 
implemented an associate contractor role among 
the four major work package contractors. This 
means that the contractors share much more 
responsibility in the design and functioning of 
"components” and "boxes” that are delivered from 
one contractor to another. This was done to 
mitigate the thousands of pieces of government- 
furnished equipment identified for delivery 
between the work package contractors. Simply 
stated, the receiving contractor and the delivery 
contractor are jointly responsible for the item until 
the item is fit or functionally demonstrated in the 
next level of assembly. This is true for both 
hardware and software. This is the first time NASA 
has utilized an associate contractor role to this 
degree. 

Another extremely important element initiated 
very early in the program is the Software Support 
Environments (SSE). The SSE will establish a 
program-wide set of rules and tools for software 
architecture and production. The SSE is mandatory 
for a highly software-driven program such as ours. 
I believe the SSE will be a model for large, complex 
programs of the future. 

With the above plans in place, program 
requirements can be established and managed, and 
the proper accountability can be identified. 

5. Maximize Margins. Margins of safety, cost, 
schedule, quality assurance, and the like must be 


maximized to the greatest extent feasible. The real 
costs and dangers come when things don’t fit or 
work as they should. Add-ons or corrections after 
the hardware and software are developed are major 
cost drivers, time wasters, and sources of future 
problems. The best time to effectively manage 
resources is early in the program in order to ensure 
maximum safety, reliability, maintainability, and 
quality assurance in hardware and software. To 
over-subscribe such valuable resources as weight, 
power, volume and crew time early in the design 
without the ability for later add-ons will 
significantly complicate the job. 

The long life of this program brings with it the 
necessity to intelligently provide the "hooks and 
scars” for future growth and subsystems upgrading. 
This is one of the most complex tasks facing us, and 
one of the most important. 

6. Maximize redundancy. But also manage it. The 
space station program has built triple redundancy 
into critical systems. To extend redundancy further 
would make the system less manageable. Once 
backup systems are in place, you have to " manage ” 
them to know you will be able to depend upon 
second and third levels of redundancy when called 
upon. 

7. Automation, robotics and Artificial Intelligence 
capability not built in will be accommodated by 
hooks and scars. We can build the Freedom station 
with today’s technology. We need to push hard on 
automation systems, robotics and expert systems, 
but not too hard. We plan in the future to 
incorporate new technologies, thus reducing long- 
term operations costs. On the other hand, Freedom 
can, through the use of hooks and scars, be designed 
to accommodate breakthroughs, and we are 
committed to incorporating such advances as they 
become available. 

8. Authority will be delegated to the lowest level 
practical and commensurate with the demonstrated 
real accountability . Unnecessary layers of 
bureaucracy take too much time to unravel. People 
take real pride in their work when they are given 
the tools and resources commensurate with the job - 
and the ultimate accountability for its success. 
Finding the right mix of accountability, 
responsibility and authority is no easy task, but 
emphasizing the necessity to do so to each program 
and project manager is mandatory. The 
management structure clearly identifies the 
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management levels and their accountabilities. If 
the accountability is not accepted, that portion of 
the program will be relocated. 

g Life-cycle cost will always be a key decision 
driver starting with development cost. The space 
station program spent much time and money in 
early definition work to identify and establish 
detailed designs that meet user requirements and 
life-cycle cost objectives within total and annual 
budgets. We know where we’re going and what it 
will take to get there. We are saving a lot of time 
and money by preparing detailed plans, and 
listening to the good advice of potential users. An 
extensive cost model is being put in place to price all 
major program decisions that have an impact on 
development and operations. Close attention to 
detail in the development phase will save enormous 
amounts of time and money in the operational 
phase. 

10. Space Station Freedom is not a n end product 
but a key element of NASA and our nation s future. 
This principle could be considered a subset of 
number 9 above. I have identified it separately to 
give it the emphasis it deserves. In the early days it 
is easy for an organization to be buried up to its 
elbows in day-to-day problems, and equally easy to 
focus on the near-term solution that compromises 
future operational costs and performance. 

Space Station Freedom will likely be our nations 
gateway to planetary exploration, lunar bases, or 
missions to planet Earth. Therefore, we cannot 
over-emphasize the need for attention to growth 
capability or economic operability. 

1 1 The international elements are vita l to Space 
Station Freedom’s success. For many years the 
United States and our international partners have 
successfully conducted complex joint space 
programs, and I am sure that this cooperation will 
continue and expand in the years to come. 
Freedom, however, will be the largest, most difficult 
and complex international cooperative space 
venture to date. Our international partners are 
contributing approximately 30% of the program 
development cost and will make a similar 
investment in the operational cost. They are 
significant members of the team. 

There will be complications, of course. The 
interleaving of sub-systems, crew roles, training, 
and a very distributed science and station ground 
operational system are some that come to mind. We 


have dealt with similar problems before, and 
learning to do this effectively may be one of the best 
avenues for cooperation in many future peaceful 
initiatives. 

12. Space Station Program Levels I and II manage 
the program; Level III and the prime c ontractors 
design, develop and fabricate Space Station 
Freedom. This principle was explicitly added to 
reinforce the fact that Levels I and II are 
management overview functions, and design and 
development responsibility rests with the Level HI 
centers and their contractors. 

13. Space Station Freedom Requirements,, Space 
Station Freedom requirements are developed and 
managed by Levels I and II and satisfied and 
verified by Level III (a subset of number 12 above). 

14. The Technical Management and Information 
System (TMIS) will be the key management tooL 
and the sooner the better. A program as large as 
this, as distributed as this, interleaved as this, 
requires an information system to gather, sort, 
compile, display, and disseminate current and 
accurate information. This includes requirements, 
design drawings, test, quality, and schedule and 
cost data, to name a few. Automated systems and 
software exist or can be built to perform this 
function in a highly automated mode. When you 
put them all together they are called TMIS. TMIS 
will allow the entire program to operate using 
timely^ and consistent information, with minimum 
input and retrieval effort. The extreme 
interdependence of each work package on at least 
one other work package requires current 
development status to be available across the 
program at a much lower level of detail than 
frequently required. TMIS will make this possible. 
Without this system in place, I do not believe it 
would be possible to maintain a proper program 
balance. 

15. Every person in the Space Station F reedom 
organization must think and perform a s a systems 
engineer or manager. This principle is most 
important but very difficult to implement. I cannot 
direct or legislate this to happen. I can, however, 
encourage our people to adopt this mindset. Most of 
NASA’s large programs in the past consisted of 
major elements such as launch vehicle stages or 
spacecraft buses that accommodated a series of 
experiments delivered to an integrating contractor 
or center for assembly and check-out. In other 
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words, there were easily identified and defined 
interfaces. This program has anything but clean 
hardware/subsystem and management interfaces. 
Virtually all decisions made at the component and 
black box level can potentially affect another 
system component design or the attendant station 
operation. Significant changes can be controlled by 
the Interface Control Document and Architecture 
Control Document systems. However, lower level 
changes are not controlled in this way. These 
changes require the engineer and manager to think 
and function as a systems engineer and to question 
the real effect each minor change has on other 
elements of the program. This process is counter to 


the natural inclination to get the hardware 
delivered on cost and schedule. The need for this 
"system leveT' consciousness is present in this 
program more than in any previous NASA 
program. This management and engineering 
discipline will be even more necessary as this 
program continues to develop. 

Here then are my guiding principles for the 
management of Space Station Freedom. It would be 
difficult if not impossible to codify any or all of these 
principles into hard, fixed policy. But I think we 
can benefit from knowing what and how a manager 
thinks and what is expected. It is part of the 
communication process. 
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Project Management: JSC’s Heritage and Challenge 


by Aaron Cohen 

Director, Johnson Space Center 
Houston, Texas 


Introduction 

Project management is one of the most trying jobs 
anyone can have, but it's also one of the most 
gratifying. As the director of the Johnson Space 
Center, I’m involved in project management 
decisions concerning the Space Shuttle and the 
fledgling Space Station Freedom every day. Earlier, 

I had the marvelous opportunity to manage two of 
the most challenging projects of my career -- 
development of the Apollo Command and Service 
Modules and the Space Shuttle Orbiter. 

Now it's my duty to pass along some of the things I’ve 
learned about project management over the years: 

• "Hands-on" experience is a prerequisite to 
effectively, efficiently dealing with the three 
classical elements of project management -- 
performance, cost and schedule. 

• Performance is not everything -- cost and 
schedule are very important. Schedule drives 
cost, and cost drives what you can produce. Don t 
ever let anyone tell you otherwise. 

• Patience, communication, honesty and treating 
people fairly are necessary elements of project 
management. You must be people oriented. 

• Contract management and project control are as 
important to project management as technical 
expertise. 

• You must do more than make decisions. You 
must make timely decisions. 

• Compromise is acceptable and is an important 
component of success. 


• Better is the enemy of the good. You can never 
solve all of the problems. 

Before I go into detail about each of these lessons, 
though. I’d like to establish a common foundation of 
understanding on which we can build. 

How Does JSC Use Project Manage- 
ment? 

JSC's organization is designed to produce solutions -- 
through project management — to the technical 
problems that stand in the way of safe, productive 
manned spaceflights. 

A project is a single, nonrepetitive, organized 
enterprise undertaken to achieve an objective within 
a specified time and cost. Project management is the 
business of creating - through a sensible sequence of 
efforts that utilize to best advantage the resources 
available - a product that achieves the objective. A 
program is a series or group of projects that achieve a 
broader goal within an overall time limit and budget. 

Our product at Johnson Space Center is to carry out 
agency objectives when they involve putting men and 
women into space, keeping them alive and productive 
while they’re there and returning them safely to 
Earth. We design, develop and operate manned 
spacecraft and train the crews that use them. We 
conduct scientific research and medical experiments 
that help us understand how space affects both 
astronauts and spacecraft. 

W^orking in concert with other NASA Centers and 
private industry, we manage projects and contribute 
to programs for America to survive, learn and 
expand. The goals our programs are designed to 
achieve include, but are not limited to, engendering 
national and international esteem, furthering 
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scientific research, bolstering our country's economy 
and strengthening our national defense. 

The JSC workforce must be able to solve very 
difficult and complex technical problems to achieve 
these ambitious program goals. They are supported 
by an organization and management process 
uniquely suited to the challenge. 

JSC’s Environment and Culture 

JSC nurtures an environment and culture that 
motivate our people to strive for technical excellence 
above all else. The environment and culture also 
encourage open, effective communication at all levels 
on the premise that no surprise is a good surprise 
when it comes to human-rated systems. 

These motivations tend to make us downplay rank 
authority at JSC and to encourage a "smart buyer" 
philosophy in the management of our contracts with 
private industry. 

The de-emphasis of formal hierarchy at JSC has its 
roots in the peer review system that dominated 
decisions within NASA's predecessor organization, 
the National Advisory Committee for Aeronautics 
(NACA). The fact that JSC's original contingent was 
a "melting pot" of civil service engineers and 
scientists, industry experts and military and former 
military specialists contributed to an organizational 
structure and management process that was tolerant 
of dissent. These cultural characteristics encouraged 
a team concept at JSC that allowed each team 
member to feel free to present his or her point. The 
emphasis was and still is on technical excellence and 
awareness, noton toeing the hierarchical line. 

This type of communication helps ensure that project 
managers are aware of all available facts, both those 
that pertain to the progress of each project and those 
that concern potential obstacles, because there is still 
one person who ultimately must make the decisions 
and be held responsible for them. Like the 
controlling stockholder in a large company, the 
project manager always has 51 percent of the vote. 

JSC's management process also provides for the best 
contributions from private industry and government 
(both civilian and military) personnel in decision 
making. This highly interactive style produces 
excellent technical decisions, but sometimes makes it 
a challenge to distinguish between public and private 
employees. Some people criticize NASA for being too 
close to its contractors. But we are dealing with an 


extremely hostile environment in space, an 
environment that does not suffer mistakes 
graciously. Strong teamwork is required to produce 
the consistently high-quality equipment and 
procedures that allow humans to survive and work 
productively in space. That kind of teamwork cannot 
be generated in an adversarial environment on 
Earth. 


We manage well because we have technical as well as 
academic experience. Government scientists and 
engineers can get hands-on experience in JSC's 
laboratories so as to manage projects from an 
educated and experiential perspective. Their hands- 
on research and development establish an 
understanding of what the various spacecraft 
systems can and should do, how much they should 
cost and how soon they can be ready for delivery. 

Beneath this interactive management process, 
however, are differences in the way people view their 
jobs. Engineering, safety, reliability and quality 
assurance and science organizations are common at 
most other Centers. At JSC, the flight crew, mission 
and ground operations perspectives add a new 
dimension to project management. The project office 
is responsible for listening to concerns and 
suggestions from these organizations and, with the 
help of the contractor, arriving at meaningful 
solutions. 


Decision making, furthermore, hinges often on some 
concerns outside of JSC. Since most manned vehicles 
carry payloads, the project office must also consider 
the advice from other NASA Centers and agencies 
that have prime responsibility for those payloads. 
External influences -such as the cultural differences 
between NASA's manned spaceflight Centers and 
research Centers, the increasingly divided 
management responsibility for manned spaceflight 
programs, the different styles of project management 
among the manned spaceflight Centers, and the 
increasingly demanding oversight of external 
authorities--also have marked effects on the 
programs and projects in which JSC is involved. 

Therefore, project management at JSC must balance 
the three classical elements of cost, schedule and 
performance and face the challenge of balancing the 
pressures caused by these diverse internal and 
external influences as well. 
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Evolution of a Matrix 

On paper, JSC is separated into line organizations 
that perform operations, engineering, and science. 
Separate from these line organizations are other 
organizations that perform support functions such as 
contracts; personnel; safety, reliability and quality 
assurance; legal; Center operations; flight crew 
operations; and public affairs. All ten organizations 
report to the Center director. 

Project management organizations must integrate 
the products of all of these organizations, coordinate 
their efforts and manage the hardware and support 
contracts as they relate to each project. They, too, 
report to the Center director, but they are ’*more 
equal’’ than the other organizations, and they also 
must be responsive to the program directors at rs ASA 
Headquarters. 

Together, these separate and distinct organizations 
intertwine to form a matrix organizational structure 
designed to support the effective management of 
JSC's project and initiative offices. To a limited 
extent, the program and project offices must compete 
for the resources provided by the line organizations. 
The line organizations must balance the needs of the 
project offices with the limited resources available 


and do their best to support all JSC program and 
project offices effectively. Decisions are made after 
consulting me and senior management staff from 
each functional directorate. This provides a check 
and balance for JSC project management decisions 
and the wise distribution of resources to each project. 

While JSC has utilized a matrix organization since 
its formation in 1961, the alignment of that matrix 
has changed. As with any organization, what shows 
up on paper is only the tip of the iceberg. JSC s 
environment, culture, motivations and experiences 
all play a major role in determining how the 
organizational matrix acts and reacts. JSC s 
environment and culture support two overarching 
motivations -- technical excellence and no surprises. 
Manned spaceflight will always contain an element 
of risk. JSC's organizational experiences have 
included both successes and failures, and crisis has 
been a catalyst for change, as it has been in other 
organizations, both public and private. 

I joined the Manned Spacecraft Center in 1962 as 
part of the industry contingent entering the Center’s 
melting pot. We were managing the Mercury, 
Gemini and Apollo programs at the same time we 
were building the Manned Spacecraft Center. In 
those days, only the separate project offices and 
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directorates reported directly to Center Director 
Robert Gilruth. All of the organizations reported to 
the Center director when developing the support 
functions, but many of the Apollo decisions were 
made exclusively by the Apollo Spacecraft Program 
Office. Since the Center really was working on only 
one program, Apollo (Mercury and Gemini were 
basically stepping stones for the lunar landing 
program), JSC’s organizational structure became a 
’’vertical matrix” with most of its activities 
supporting that program. 

The Apollo 204 pad fire that claimed the lives of 
astronauts Gus Grissom, Ed White and Roger 
Chaffee in 1967 represented an organizational crisis. 
It became obvious that the ’’vertical matrix" allowed 
the program office too much autonomy. Dr. George 
Low, who was also JSC deputy director, became 
program manager and brought a broader perspective 
and management style to the job. He required the 
participation of all JSC line organizations to a 
greater extent than had been the case before the 
Apollo fire. He expanded the Center’s management 
process to include all of JSC’s senior functional 
managers in major Apollo Program decisions, JSC's 
director and his senior staff were assigned a check 
and balance responsibility for the program. What 
had been a limited communication process between 
the program manager and each of the JSC 
organizational elements became more open, and the 
entire Center senior staff was encouraged through a 
more participative management style to help make 
the decisions of the program. 

A separate safety, reliability and quality assurance 
organization also was established. The Center 
director began to oversee all decisions, whether they 
involved project management, operations, 
engineering, science or support. JSC’s 
organizational structure has changed little since that 
time. 

A Different Emphasis 

I was project manager for the Apollo Command and 
Service Modules (CSM) from 1968 to 1972, and for 
the Space Transportation System Orbiter from 1972 
to 1982. Throughout both projects, one of my 
principal responsibilities was to constantly make 
trades between performance, schedule and cost 
Today’s project managers are making similar trades. 

While the need to make these trades is a constant 
characteristic of project management, the priority 


each assumes in relation to the other can change 
drastically. These priorities are driven by both 
internal and external forces that establish a goal, a 
mission and a management philosophy for each 
program. They are rarely black and white. More 
often than not, such priorities are shades of gray that 
lighten and darken on a case-by-case basis using the 
best information available at the time. 

As I managed the CSM project, the priorities that 
normally held were performance first, schedule 
second and cost third. Our first challenge was to 
achieve the goal -- to build the Apollo spacecraft, 
train the crews and fly the missions that would 
accomplish the material goal of putting men on the 
surface of the Moon and returning them safely to 
Earth. Our second most pressing challenge was to do 
it on the schedule stipulated by President Kennedy. 
The element that received the least overall emphasis 
was cost. 

At the height of the Apollo Program, nearly 4 percent 
of the national budget went to NASA. By contrast, 
NASA now receives less than I percent of the 
national budget to fund the Space Shuttle and space 
station programs. During Apollo, there were no 
starts and stops on the production lines. As we built 
the Space Shuttle Orbiter, we repeatedly had to 
assess which subsystems could wait to be produced 
and which could not because of variations in 
budgetary commitments to the space program. 

The Space Shuttle program was conceived as a more 
cost-effective means of providing access to space and 
a necessary way of providing transportation to and 
from a future permanently manned space station. 
For a manned space station to remain operational for 
long periods, it would need continued resupply and 
crew exchanges. A vehicle was needed to carry 
people and cargo into orbit, return both safely to 
Earth and do it over and over again - all on a tight 
budget. The goal had changed from reaching a 
destination to developing a transportation capability. 

The order of priorities that normally held for the 
Space Shuttle Orbiter was performance first, cost 
second and schedule third. NASA was still required 
to achieve the desired level of performance, but 
because of budgetary constraints, cost requirements 
had to take precedence over schedule achievements 
in the early stages of the shuttle program. 

I am not going to say that one program was easier to 
manage than the other, but the facts are that the 
programs of the 1970s placed a much greater 
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emphasis on cost than the programs of the 1960s, 
This was not all bad because it forced us to pay closer 
attention to cost-effective technical solutions, and to 
keep in mind the goal of providing a less expensive 
means of access to space. And I don't mean to infer 
that safety and reliability can be sacrificed. As I 
mentioned earlier, performance was always the 
number one consideration. You can still obtain a 
successful product in terms of performance, cost and 
schedule, but when cost takes precedence over 
schedule, the ability to make the right decision the 
first time becomes more important. More 
productivity and innovation are needed to solve 
problems of equal or greater complexity with less 
money. This placed an added demand on the project 
managers because they were required to instill 
resource management discipline in technical 
organizations that were not used to giving so much 
attention to resource allocation. 

The Apollo vehicle was not as technically 
complicated as the Shuttle Orbiter. However, the 


Apollo mission was much more complicated than the 
Shuttle’s mission. During the Apollo program there 
was the luxury of solving problems by using multiple 
paths, due to resource availability. During the 
Shuttle program, budget constraints forced us to 
choose from among possible paths early and follow 
the one that looked the most promising. 

Avoiding Pitfalls 

Whatever priorities are dictated by the environment, 
a project manager can never equally satisfy all 
elements of project management. There is no exact 
project management formula or equation for making 
performance-cost-schedule trades. But the lessons I 
have learned from people like Robert Gilruth, Max 
Piaget, Chris Kraft and George Low -- and from my 
own experience -- tell me that there are several 
important principles in maximizing the probability 
of success. Those factors sometimes contradict one 
another and they must be applied on a case-by-case 
basis, but they are nonetheless valuable. 



APOLLO PTV-1 ACTIVITY -- View of the Apollo Spacecraft PTV-1 inside Chamber A, 

SimSn Laboratory, Manrr^ed SpaJetraft Comer, prior to roannod thorroal- 


vacuum testing. 


ORIGINAL PAGE IS 
OF POOR quality 


11 


First, you must fearlessly base your decisions on the 
best information available. As a project manager you 
will have many different considerations with regard 
to each programmatic issue. Simply by making a 
decision, you ensure that you probably will be right 
more than half the time. 

Many times during the life of a project, a project 
manager will be faced with decisions that need to be 
made in a timely fashion, and either all the data is 
not available or it will not become available in time. 
In other words, the time and effort spent in trying to 
obtain additional information may not be 
worthwhile. A specific example of this occurred 
during the early design phase of the Orbiter. The 
avionics system was being formulated and a 
microwave scanning beam landing system (MSBLS) 
was being considered as a navigation aid. At the 
time, the MSBLS was pushing the state-of-the-art. 
The question before me: Should I use current, proven 
technology or should I try to push the state of the art 
and wait for such an advancement in the technology? 

I based my decision to push for the new technology on 
the data I had and the desire of my team to use the 
system. We made a decision, and it proved to be 
correct. 

Second, you must make decisions in a timely manner. 
If you are decisive early and are wrong, you can still 
correct your error. During the Orbiter design, 
development, test and evaluation phase, I was forced 
to make many trades in terms of performance, cost 
and schedule. On one particular occasion, I was 
reviewing thermal system structural test 
requirements that contained a number of articles 
such as parts of wings, parts of the mid and forward 
fuselage and their thermal protection systems. The 
technical team needed to test all of the articles, but 
they were too large to test all at once, and I had a 
limited budget. After spending a full Saturday in 
review of all the test articles, I eliminated several 
despite the extreme concern of several of the 
technical experts I had supporting me. Weeks later 
they came back and argued their point of concern 
again. This time, their point struck home and I 
reversed myself and put the test articles back into 
the program. By making a timely decision, I had 
given myself a chance to correct a potential error. 

Third, if you can fix a problem by making a decision, 
do it. During the checkout of Apollo 11, the Inertial 
Measurement Unit (IMU) of the lunar module was 
slightly out of specifications in gyro drift. The 
analysis showed that you could accept a little more 


degradation and still perform the mission. The 
questions before management; Do we understand the 
reason for the gyro drift, and could this lead to a 
greater degradation and threaten the success of the 
mission? Changing an IMU out of the lunar module 
on the pad was not an easy task, and we would be 
risking major damage to the fragile structure of the 
lunar module if one of the heavy instruments were 
dropped during a pad change-out. A group of us 
discussed this problem with George Low, then Apollo 
program manager. We strongly recommended to him 
that we should not change out the IMU. His 
comment was: "If you can fix a problem by making a 
timely decision, do it." We replaced the IMU. 

Fourth, always remember that better is the enemy of 
the good. You can never solve all of the problems. If 
you have obtained an acceptable level of system 
performance, any "improvements" run the risk of 
becoming detriments. Right now, we are struggling 
with this very situation as we try to improve the 
design of the solid rocket motors and add emergency 
egress systems to the Orbiter. Each improvement 
brings with it a price in terms of weight. Each 
additional pound reduces the margin we have in the 
amount of thrust available to reach orbit. We have 
had to ask ourselves, "At what point do these new 
safety features become liabilities?" 

Fifth, don't forget how important good business and 
contract management are to the successful operation 
of a contract. Project managers must realize that 
when they manage a contract they should do their 
best to be fair to both the government and the 
contractor. In order to do this, they need strong 
project controls on budget, schedule and 
configuration. The project manager must be sure the 
changes that are made are negotiated promptly and 
equitably for the government and contractor. 
Fairness in dealing with the contractor is the most 
productive way to do business. You want to penalize 
when appropriate, but you also want to reward when 
appropriate. To establish what is appropriate, you 
must set the ground rules early. The first signs of 
project management failure are budget overruns and 
schedule slips. This can be understood and 
potentially avoided or minimized by good project 
control and contract management. 

Last, and most important, you must be people 
oriented. It is through people that projects get done. 
Dealing with people is extremely difficult for many 
project managers who have an engineering 
background and are more comfortable working with 
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an algorithm than explaining how to use one. Good 
project managers surround themselves with talented 
people who will speak up when they believe they are 
right. They make themselves available to their 
bosses and to the people who support them. They 
listen when people express their concerns and make 
people want to express their concerns by explaining 
decisions that contradict the advice they've been 
given. They accept criticism without being defensive 
and are able to reverse their decisions when they are 
wrong. 

One of the most vivid and memorable experiences 
I’ve had in this regard happened during the 
preparation for Apollo 8 in early December 1968. 
The preparations had been going very smoothly 
without any big issues needing to be worked for 
several weeks. Then it happened. About two weeks 
before the flight I was told by the contractor, North 
American Aviation, and JSC propulsion subsystem 
managers that we had a potentially serious problem 
with the service propulsion system (SPS). We had 
just finished some tests in the configuration that we 
were going to use for lunar orbit insertion. 

Apollo 8 was going to place the CSM on a free-return 
trajectory, which meant that if we did not perform an 
SPS burn behind the Moon the spacecraft would 
automatically return to Earth. The SPS fuel injector 
was fed by a pair of redundant systems. We wanted 
both of them to be active during the lunar orbit 
insertion burn so that if one feeder line 
malfunctioned, the other would get propellant to the 
SPS. The tests we had just finished were in this 
configuration, but it was the first time they had been 
used and both lines had been dry before the test. The 
tests showed that if we started the burn with both 
lines dry, a pressure spike occurred that could cause 
a catastrophic failure in the SPS. If both lines were 
wetted, however, the pressure spike would not occur. 

I got very upset when I was told this, but the test 
engineers stood their ground. They told me very 
firmly that the problem had to be addressed, and they 
presented a good solution. By firing the SPS on a 
single system out-of-plane burn during translunar 
coast - which would not disturb the free-return 
trajectory — we would have both systems wetted by 
the time we needed to use them together and, hence, 
avert the high-pressure spike. 

Now it was my job to call my boss and let him know 
what I knew and how to fix the problem. I had no 
qualms about doing this because my boss, George 


Low, had taught me several important things by his 
actions and words: get out and touch the real 
hardware; pay attention to detail; when things go 
wrong, look for innovations, the unusual solutions, or 
try to meet your commitment no matter what; and 
have great respect for your fellow human beings. 

Management Toolbox 

The surgeon has a scalpel, the general has a battle 
plan and the project manager has still another 
arsenal of tools. The adept and effective use of these 
tools is a critical factor in the success of the project 
manager. Because almost 90 cents of every dollar 
budgeted for NASA is spent by a NASA contractor, 
these tools are used to assist the project manager in 
the contract management responsibilities. 

The basic project management tool is the contract. A 
contract baseline is established through the 
development of a statement of work, a segmentation 
of the work by use of a work breakdown structure 
once a contract baseline has been negotiated between 
the contractor and the Government. Then the project 
manager must maintain a continuing awareness of 
the status of the project. The tools of the project 
manager at this stage include management 
reviews where technical and business staff conduct 
in-depth assessments of the project with counterparts 
from industry. 

The project manager must delegate a portion of the 
responsibility to the matrix organization structured 
to support the project. The backbone of this matrix 
assignment is a three-party team composed of 

subsystem management, project control, and the 
contracting officer. 

The best management tools are the ones that allow 
communication to flow in the most efficient manner. 
By efficient, I mean the presentation of a large 
amount of data in a small amount of time in a format 
that allows decisions to be made. I have primarily 
discussed the matrix management systems that JSC 
used during the Apollo and Shuttle programs and the 
term ‘‘subsystem manager." 

Every day from noon to 1 p.m., I had a stand-up 
briefing in a control room on various subsystems 
and other aspects of the Orbiter project. We held 
these meetings in a room that had been structured 
with schedule control boards mounted on the 
walls. These boards served as our controlling display 
of the total project. A particular project individual 


was assigned to maintain current project status on 
each control board. This allowed a great deal of data 
to be transmitted in a very efficient manner. Issues 
were laid out for discussion and I then could schedule 
decision-making meetings. This proved to be a very 
efficient way in which to do business. 

The next level of review that was created was a 
weekly or an "as needed" Technical Status Review 
meeting. The purpose of this review was to have a 
combined JSC technical and contractor review by 
teleconference. 

One of the most critical project management tools 
that works in conjunction with the project manager’s 
use of the contract and management review concept 
is the change control process. I used the change 
control process as a way to maintain a disciplined 
and detailed accounting of my contract baseline. At 
the heart of the change control process is the Change 
Control Board. The Change Control Board was a 
weekly meeting of JSC directorates and the 
contractor to make formal decisions on proposed 
changes. 

The management tool used to ensure that the prime 
contractor was carrying out the contractual 
responsibilities in the most effective and efficient 
manner possible was the monthly Orbiter 
Management Review (OMR). The OMR was held 
at the contractor’s facility and reviewed the total 
project. This review normally took two days. It was a 
review of the financial, contractual and technical 
status of the project. 

These sessions at the contractor’s facility enabled me 
to conduct an in-depth review of the status of the 
contractor’s work in the same manner that I had been 
able to review the government teams* work in my 
daily noon meetings. 

Another project management tool that aided the 
communication within JSC and from JSC to our 
contractor was the Award Fee process. The 
opportunity to identify for the contractor specific 
areas of project emphasis and to couple this emphasis 
with the awarding of a contractor fee based upon 
accomplishment of specific project objectives served 
as a very powerful management tool. I use a 
performance measurement system to help me 
objectively evaluate how accurately the contractors 
achieve their targets. 


Conclusion 


Project management is the heart of NASA’s success. 
NASA in its relatively short lifetime has made some 
spectacular manned spaceflight accomplishments. 
Landing a man on the Moon and returning him 
safely to Earth, linking a manned U.S. spacecraft 
with a Soviet craft, launching and operating a 
manned space station, Skylab, for several months, 
and developing and operating the Space 
Transportation System--all have claimed the 
attention of a world that is inspired and challenged 
by technological advancement. Add to these all the 
unmanned probes of the universe, mapping of our 
solar system, fly-bys of orbital planets and the 
scientific advances in earth-sensing and aeronautics 
and you conclude that America has been well served 
by NASA. 

JSC’s product has been the formulation, 
management and execution of projects that put men, 
women and unmanned craft into space and allow 
them to do useful scientific research and work. All of 
these NASA endeavors are accomplishable because 
of NASA’s utilization of project management. But 
there are several characteristics of the NASA 
utilization of project management techniques that 
are somewhat unique and thereby have served as an 
inspiration not only to the United States but to the 
free world. 

For the most part, NASA projects have had a clear 
statement of their goal or purpose, such as to land a 
man on the Moon and return him safely to Earth. 
Second, NASA projects have had a precise schedule 
for achievement of these goals. Third, NASA projects 
have been open for the world to observe. Because 
part of NASA’s charter is to disseminate information 
about aeronautics and spaceflight, the whole world 
has been a spectator for our daily project 
accomplishments and failures. Fourth, at NASA we 
do more than produce and deliver "widgets" as many 
businesses do. We develop and build widgets as part 
of our work, but we build them to help us achieve our 
mission objectives. The world follows the successes 
and failures of our widgets in both their development 
and their use. 

These characteristics have placed very great 
demands on the NASA project managers. The 
intensity of these demands has required an 
uncommon attention by NASA project managers to 
an openness and clarity of communication, a 
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dedication to the project task and uncanny, almost 
single-minded, attention to detail. 

As acute as these demands have been and as well as 
we have responded, I can guarantee that we will have 
to redouble our efTorts in the future. The complexity 
of our projects will increase. The cost constraints will 
continue, and probably tighten. We will have to 
manage multiple programs, and make them work 
together as in the case of the Space Station Freedom 
and the Shuttle. We will be managing programs 
with lengthening or never-ending lifespans. 
International participation will increase and 
intensify. NASA's Centers and support contractors 
will work even more closely. We'll begin working 
with more private sector commercial ventures. 

How we react to these intensified and diversified 


demands is the key to our future. Our reactions 
should be driven by the lessons we’ve learned, but we 
must move beyond those basics. Our project 
management capabilities must evolve in directions 
that have not yet been defined. We must carefully 
evaluate every adjustment and improvement we 
make to our program management methods, just as 
we evaluate every change in a spacecraft’s systems to 
be sure that the change is beneficial and that the 
repercussions of any side effects are not detrimental. 

I am confident we can meet the challenges today and 
in our future through the judicious use and continued 
refinement of our project management techniques. 
There is no simple formula for the success of project 
management, but the rewards of a job well done and 
witnessed by the whole world are well worth the 
effort. 



Back on April 12. 1981, just a law caconds past 6 a m., Spaca Shuttia Columbia ■>«!!'< 

Kennedy Space Center, marking the launch of the Shuttle Era m manned spaceflight. STS-1 carried 
CommaJIder John W. Young and Pilot Robert L. Crippen toward an Earth-orbital mission which represented 
the start of a new era in space transportation for NASA and the world. 


original page is 
or POOR quaut? 


15 



Shared Experience in NASA Projects 

Some Tips and Observations 

Wallops Island, Virginia 
August 25, 1987 


by A. Guastaferro 

Vice President, Space Station Program 
Lockheed Missiles & Space Co. 


It has been a real opportunity to serve in all but the 
first five of the 30 years of U.S. spaceHight. For 
program and project managers, these three decades 
have been filled with enormous challenge and 
exciting opportunities, mainly because there have 
been no clear precedents for managers. In those 
early years, we had to progress incrementally, if you 
wish. Each step along the way, NASA and industry 
expanded the knowledge base and technological 
capabilities to a point where each individual project 
became incrementally more complicated, expensive 
and challenging. Management of these projects-- 
from the small unmanned payloads to the medium- 
sized Mercury-Gemini to the larger payloads of the 
Apollo-Skylab era--like wise presented new 
challenges and demands. The old ways of doing 
things simply did not work in this new complex and 
high-tech environment. 

Nor will they work in the current phase of spaceflight 
development, with multiple payloads in the Shuttle 
era. New tools, new techniques are required as 
NASA and industry enter the long-term aspects of 
space station design, development and operations. 

Yet, we all look back with pride to spaceflight 
programs of the past that worked efficiently. We 
respect the management tools that led to mission 
success in earlier projects. As we look toward the 
management challenges of spaceflight development 
of the 1990s, we must reflect on the accomplishments 
and failures of the past and apply the lessons learned 
in a constructive way. The NASA project manager 
represents the leadership of the U.S. in space 
exploration. It is critical that the NASA project 
manager learn from the past to build a space 
program second to none. 


In other words, there are some things worth saving, 
others to discard and still more to build upon. When 
you add up all the marvelous advances and successful 
missions of the past 30 years of U.S. spaceflight, you 
canT help but think that the partnership between 
NASA and industry has become one of the more 
remarkable management feats of all time. The 
synergy and cross-fertilization of this partnership are 
worth exploring. 

My purpose here is to provide a perspective of both 
NASA and industrial project management issues as 
they relate to research and development activities. 
NASA project managers represent the leadership of 
an organization. As such they have accepted a 
responsibility— better stated, an accountability--for 
the total aspect of a particular task. They must 
accept cost and schedule responsibility, along with 
the technical aspects of the assignment. A good 
manager views this assignment as if it were a 
personal business and tries to determine 
effectiveness by some predetermined measurement 
system. Following are observations on project 
management issues from both NASA and industry 
points of view. 

First of all, the initial formulation of a NASA project 
is extremely critical to mission success. The 
advocacy phase must be carried out with very careful 
planning, timely marketing and with a clear 
understanding of the organization s mission and 
available resources. On the government side, the 
establishment of an approved project may take years. 
Early in the advocacy process, a strongly supportive 
outside constituency is needed, to help secure a 
budget line item for the next fiscal year. This 
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constituency should include several aerospace 
contractors willing to direct their new business 
resources toward the project in return for an 
opportunity to compete in the design and formulation 
phase. 

The industry formulation process is not very 
different. Contractors have limited resources and a 
large spectrum of opportunities. The successful 
contractor gets involved early, assigns qualified 
people, provides adequate resources and maintains a 
strong relationship with NASA so that critical 
resources are focused to the project objectives. 
Contractors are available to help NASA in the 
selling of the project during the formulation period. 

Accountability 

In accepting accountability for an organization unit, 
make sure you understand its objectives. In addition, 
find out what inter-organizational relationships are 
required and where your resources and constraints 
will come from. Understand what is expected of your 
unit. Get a contract between you and your boss, you 
and center management, you and headquarters, you 
and your family. If internal and external forces are 
going to influence the performance of your unit, get a 
commitment to: 

• Cost 

• Schedule 

• Technical performance 

• Risk 

Make sure you are given sufficient authority to carry 
out your task. Don’t put yourself in a "no-win” 
position at the outset. Get an understanding--and 
then the commitment. A successful business always 
does. 

When I look back on my NASA years, it strikes me 
that the government system ordinarily does not 
provide a natural environment for full 
accountability. The typical organizational structures 
and the non-profit environment are impediments to 
accountability. On the other hand, the industrial 
R&D managers assume fiscal responsibilities very 
early in their career and are better prepared for 
project management responsibilities. Perhaps NASA 
managers should develop their own methods outside 


of the organizational system to provide the stimulus 
for accountable management. Essentially, the skill 
is there-but the environment is not. 

Establish a Standard 

After receiving a clear understanding of the 
management assignment and the resources and 
schedule constraints, make sure you develop 
specification, a standard of performance. Make your 
specification realistic and flexible. (Many a manager 
has died of hardening of the categories.) Divide your 
work into a logical structure. Avoid false 
competition, unnecessary overlap, or gaps. Find the 
right person for the right job. Delegate a portion of 
your contract to your subordinates and depend on 
them. 

I believe that the discipline and the environment of 
NASA encourage individual performance in the 
development of hardware/software capabilities. 
Industry, driven by the profit motive, will find ways 
to meet performance requirements that avoid strict 
adherence to rules and regulations, NASA is 
experienced in setting standards but not compliance 
to them. Simply stated, it is easier to write the rules 
than to follow them. I believe that a healthy 
exchange of technical experience can benefit both 
parties. 


Make a Plan 

Establish an integrated plan. Assign accountability 
for accomplishment. Make sure you understand the 
critical elements and provide sufficient schedule 
margin for "work-arounds.” Review performance 
versus plan, frequently. Detailed schedules should 
be realistic. (Be careful--do not become overly 
optimistic.) I believe in pressure scheduling only to 
meet a crisis. Crisis or stress management in a 
research environment should be the exception and 
not the rule. Schedules and plans should be highly 
visible. 

There seems to be very little difference between 
planning in NASA and the aerospace industry. Both 
organizations are highly tuned and efficient in the 
aspects of integrated planning, and both have 
developed performance measurements systems 
significantly useful to the decision-making process. I 
cannot find any difference in technique, process, or 
effectiveness Perhaps we have trained each other to 


be consistently good and bad in the areas of planning, 
review and analysis. 

Communications 

A good manager is a good communicator. You should 
develop a motto of "no surprises." Communicate 
frequently. A few ideas: 

• Weekly staff meetings 

• Management by walking around 

• Electronic management information systems 

• Teleconferences with contractors and grantees 

• Thorough requirement and design reviews 

• Frequent status reviews 

• Outside reviews 

• Visits to outside work activities (and show 
interest) 

• Finding a way to involve your boss 

• An open-door policy for your people 

• Curiosity (ask questions) 

In my short time in industry, I have been impressed 
that industry is far more bureaucratic than NASA in 
its communication methods. For instance, customer 
briefings are critiqued to a far greater extent than I 
experienced at NASA. It is apparent that the success 
of the project and, in turn, the company, are critically 
assessed. NASA's approach is to assume a degree of 
confidence in the program and competence in its 
people. It is an attitude that I appreciated and 
somewhat miss. 

Contract Management 

The easiest way to improve contract performance is 
to concentrate on the selection process. Make sure 
your contractor has the experience and personnel to 
carry out the technical aspects of the contract. 
Remember, a bad marriage between the government 
and contractor will always lead to a costly divorce 
settlement for the government. Some thoughts to 
keep in mind: 


• Guard against expansion of requirements 

• Expect the unexpected technical problems 

• Temper optimism regarding schedule and cost 

• Watch for engineering changes that make things 
better instead of make them work 

• Expect an underscoping of the project control 
function 

In industry, the contracting relationship is normally 
between two aerospace contractors. There is far less 
formality in this type of a relationship and, as a 
result, a lot more difficulty in full compliance and 
implementation. Although I have found the NASA 
procurement process to be stifling, it has benefits in 
long term implementation and compliance. 

Getting Your Vote Canceled 

One barrier to effective communications is the fear of 
senior management involvement in detailed decision 
making. It has been my management philosophy 
that when my boss is in the same meeting with me, 
my vote is canceled. This concept places the manager 
in the delicate position of deciding which meetings 
the boss should attend. 

The industry performance incentive program insures 
your boss's personal interest in anything you do that 
can affect the bottom line and the boss’s paycheck. 
However, a successful project leader must have 
control of the resources necessary to ensure success. 

The Golden Rule 

In both NASA and industry, the golden rule applies. 
The manager with the gold-rules. Make sure you 
receive and control the money needed to accomplish 
your mission. If either your boss or your boss s boss 
controls the money, they in fact control the project. A 
project manager simply must control ail the 
resources necessary for mission success, or some 
method of accountability must be devised. 


Find Something to Count 

After you understand your objectives, establish your 
baseline and obtain a contract and resources, it is 
then necessary to check your progress by frequent 
reviews and analyses. Managers in government 
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can’t measure performance against the industry 
profit milestone. But they can find things to count 
and they can measure progress by establishing 
performance standards and by variance reporting. A 
few examples of countable items: 

• Data points 

• Computer runs 

• Documents released 

• Reports published 

• Pieces of hardware 

• Value of work performed 

• Money spent 

• Manpower expended 

• Time lost or saved 

• Test hours 

• Major milestones reached 

• Review points completed 

Performance Feedback 

Do not be afraid to alter plans, specifications, and 
resources, based on past performance and future 
expectations. Good managers know where they are 
going by a critical analysis of where they have been. 
When changing the baseline, make sure you 
communicate up and down and that all are working 
to the revised plan. 

A good manager stays involved in the details through 
an effective review program. Stress early problem 
identification and aggressive application of remedial 
measures. 

As in planning, both NASA and industry do an 
outstanding job of performance measurement. 
Mission success is a goal in both organizations, and 
management tools have been developed for effective 
control of large R&D projects. 

Cost Management 

The first rule of good cost management is to set aside 
dollars for a rainy day. Identify reserves and develop 


a management plan for control and allocation of 
those reserves. Perform a risk analysis and identify 
the program cost drivers. Have a shopping list of cost 
offsets to provide additional margin. Make sure you 
can reduce performance and schedule constraints to 
reduce cost. My industry experience indicates that 
the ability to retain cash reserves for effective cost 
management is extremely difficult. Matrix 
organizations tend to assign resources to functional 
organizations, thereby making it difficult to retain 
reserves. Industry can learn much from NASA in the 
art of contingency planning. 

A Strong NASA/Contractor Project 
Relationship 

Experience shows that the best relationships hinge 
on two major factors. First and foremost, the two 
parties must establish a strong and active 
communication network. Every effort should be 
made immediately after contract to start to generate 
an effective reporting system with strong emphasis 
on the early identification of problems and 
improvements in communication methods and tools. 
The parties must also agree to complete near-term 
action items early, to identify '"one-on-one” 
relationships clearly and to secure senior 
management participation. 

The second factor is to establish an honest and open 
relationship. This usually takes hard work on the 
part of both parties. It is critical to the success of the 
project that both parties are dealing from the same 
data base when formulating policies and making 
decisions. Remember, the NASA and the contractor 
are both interested in the same result— a successfully 
completed project within the cost and schedule 
constraints prescribed by the NASA. Experience in 
industry indicates that the profit motive is important 
to the contractor but not at the expense of NASA 
dissatisfaction. I believe the long-term involvement 
in civil space and aeronautics is rated higher than 
profit. The challenges of a NASA program help 
attract new technical skills to a company, thereby 
fostering long-term growth. 

NASA managers should be sensitive to this emphasis 
on long-term capabilities vs. short-term profit by 
stressing a complete and honest relationship. If 
changes are caused by a NASA decision or event, the 
NASA team should expect the contractor to receive a 
fair adjustment in both cost and fee. On the other 
hand, if contractors have performance problems, they 
should be prepared to fix the problems without 
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benefit of a fee adjustment. Both parties striving 
toward this type of open and honest exchange will 
establish the trust so critical to the achievements of 
project objectives and mission success. 

This open and honest relationship between NASA 
and contractor hinges upon strong communication. 
The project manager can communicate in a number 
of ways: by computer, telephone, voice, the written 
word, gestures, tone, style, etc. But the successful 
project leaders communicate best by personal 


example. They are role models for the next 
generation of managers. Their ideas and aspirations, 
especially their vision, are communicated even more 
clearly than their words. That vision will have 
impact far beyond the day-to-day project and will 
invariably extend to relationships within NASA, the 
cooperation of contractors, the team spirit for mission 
success and the users of the project-the customers, 
taxpayers and beneficiaries of an on-time, on-budget 
project. The ripple effects of a well-managed project 
(as we have seen from earlier spaceflight programs) 
will last for years if not generations. 


My Lessons Learned 

1 . Never lose your capacity for enthusiasm. 

2. Never lose your capacity for indignation. 

3. Never judge and classify people too 
quickly; first assume always that they are 
good. 

4. Never be impressed by wealth alone or 
thrown by poverty. 

5. If you can't be generous when it's hard to 
be, you won't be when it's easy. 

6. The greatest builder of confidence is the 
ability to do something, almost anything, 
well. 

7. When that confidence comes, strive for 
humility, for you aren't as good as all 
that. 

8. The way to become truly useful is to seek 
the best that other brains have to offer. 
Use them to supplement your own, and be 
prepared to give credit to them when they 
have helped. 

9. The greatest tragedies in work and 
personal events stem from 
misunderstanding. Communicate. 
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Controlling Resources in the Apollo Program 


by C. Thomas Newman 

Assistant Deputy Administrator 
NASA Headquarters 


Following is a slightly modified version of a paper 
written as part of our training effort for new staff 
members and interns in the Apollo Resources Control 
group in the Office of Manned Space Flight. Some of 
the points may seem elementary today, but 1 think 
many of the points are worth repeating. My tendency 
is to emphasize personal involvement and 
responsibility for estimates and conclusions. To some 
extent, this paper reflects my concern that the 
emphasis on automation tends to de-emphasize these 
concerns. Nevertheless, today I would put more 
emphasis on cost rate analysis, discussed below. 

What We Are Trying To Do 

One objective is to make sure that the budget plan 
really reflects the intent of management. This 
means the estimates must cover the program that 
management has approved and that there must be a 
reasonable basis to believe that the estimated 
amounts will buy what they are intended to. 

Conventional budget reviews have been directed 
toward making sure the estimates are not padded. In 
R&D programs, the real problem is often one of 
underestimating what it takes to do a job, in both 
time and money. Any energetic agency has more 
good ideas than dollars. The budget process is aimed 
at getting as much program as possible within the 
dollars available, and at the same time making sure 
that we do not unknowingly take on commitments 
which we cannot support within the available 
funding. An important part of our analysis effort is 
to make sure that the estimated resources are a 
reasonably valid reflection of what it would really 
cost to do each option. 

An essential function of our office is to get 
obligational authority from the review levels above 
it. This means preparing and supporting budget 


requests and, more importantly, preparing our own 
top management to support the budget request. 

Looking in the other direction, we must determine 
how much obligational authority the offices really 
need. What we want to do is to provide for a tolerably 
sufficient but somewhat uncomfortable allocation. 
There is no question in my mind that a certain 
amount of pressure caused by funding levels below 
apparent demands is essential to any sort of 
management discipline. 

Other vital activities in monitoring progress are to 
determine if the use of funds is in accord with the 
agreed-to plan or known intent to deviate from the 
plan; any units are running too far over or under 
availability ; or reallocation of funds is needed. 

Another function is to keep management informed. 
The key here is to sort out the type of information 
and the level of detail that are really useful to 
management. This depends in large part on the 
personality and interests of the manager. I believe 
that the most common mistake in this regard is to try 
to give the manager too much unfocused detail. 

Approach: How We Do It 

The way you work depends somewhat on your level 
in the organization, the management relationships 
with other offices, and the people involved. I think, 
however, some general techniques are applicable to 
almost any sort of budget review function. 

Personal contact is usually more important than 
paper work. In many organizations, you get your 
important points across to top management by 
telling them rather than writing to them. You learn 
more about what is really going on by talking to 
people than by reading reports. One important 
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technique is assigning reliability factors to people. 
Over a period of time you come to know that 
information received from some sources will almost 
always be right and well considered, whereas other 
sources are relatively unreliable. Other people will 
form an evaluation of your reliability factor with 
respect to both the information they get from you and 
the use you are likely to make of information you get 
from them. Establishing a good reliability factor for 
yourself and assessing that of others are two of the 
most important things you do. 

The concept of correlation and probability testing 
applies to just about any sort of learning and 
evaluation process. Common sense correlation is, 
to my mind, the most important technique in 
assessing data. This means that, over time, you 
formulate an idea of what things ought to cost and, 
when any new estimates are presented, you have a 
basis for comparison. You are constantly testing the 
probability that what you hear or read is correct. 
Does it make sense when put beside what you 
already know? 

Besides correlating various inputs of information on 
costs, you need to compare dollar estimates with non- 
fiscal data such as progress against scheduled 
accomplishments, complexity of work to be done, 
possible knowledge of other work assigned to the 
same organization, and other relevant factors you 
know. Multiple sources of data should be sought and 
the results constantly compared. 

The type of correlation I have in mind is more 
intuitive than mechanical. It becomes a habit; it 
grows on you. To promote its growth, you need to 
develop a reservoir of knowledge on your own 
programs and related programs. You need an 
understanding of what needs to be done to make the 
program succeed. You need a general grasp of the 
technical problems, the management problems, the 
political environment, and the capabilities of the 
people we are relying on to do the job. It takes time 
and effort to acquire this background. You need to 
conscientiously study the hardware and operational 
aspects of the program. You also need to spend time 
working with the numbers. You need to "own” the 
figures. I believe that you are more likely to develop 
this by personally working with the numbers rather 
than relying on automated data. Once you have done 
enough of this work with the proper frame of mind, 
the correlations will come naturally. Your mind will 
accept or reject figures, often without knowing the 
specific reasons, but you will usually be right. 


A great deal of work has been done to establish 
mechanical means of correlating funding estimates 
with factors such as weight, complexity, speed, size, 
production rates, etc. So far, these efforts have been 
only partly successful and do not provide a substitute 
for well-developed intuitive judgment. 

It is almost always true that the whole is better than 
the sum of the parts. In developing estimates, I 
believe in building up pieces to the extent that time 
and knowledge permit a reasonable job to be done, 
but this should always be correlated against a broad 
scope look at the overall picture. If there is a conflict 
in the results, I would base my judgment on what a 
common-sense look at what the overall picture says 
rather than a meticulous addition of the pieces. I 
believe that excessive immersion in detail is not only 
tedious but also can be detrimental to doing a good 
job at the overall program level. A balance between 
specific knowledge of details and judgment at the 
total level is needed. 

Cost rate analysis is an important way to look at 
overall program trends. Contractors build 
momentum which is not easily changed. It is like a 
river that keeps on flowing no matter how hard you 
blow on the surface. In most cases you can safely 
judge that cost and manpower utilization rates will 
not change rapidly unless some very strong pressure 
is applied or some unusual program factors are 
involved. 

A commonly misunderstood technique is what I call 
the "spot probe.” In reviewing an estimate, you probe 
in depth into a specific item. You ask difficult and 
detailed questions and generally give the person 
defending the estimates a hard time. This can be 
done in a civil manner. You are not really interested 
in the specific details, but you are trying to 
determine how carefully the estimates have been 
developed. Probe several points. You should not 
judge too much by a test of any one area; but by 
probing several areas, you do get a feeling for the 
degree of confidence you can place in the work that 
went into developing the estimates. Be careful in 
applying this technique. Do not embarrass people 
unnecessarily. You will be dealing with them later. 
If a proper rapport is maintained, you can work with 
them to correct any deficiencies you find. 

Communications Upward 

The work of building a budget or resources plan and 
monitoring performance against the plan is wasted 
unless: 
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• It enables you to do a job that you need to do 

• It gives your management the information it 
needs to do its job, or 

• It answers questions that need to be answered. 

Give management the answers it really needs and 
wants— not the answers you think it would be nice for 
them to have. They already receive more 
information than they can handle. If a part of 
management has been delegated formally or 
informally to the resources office, I believe that 
authority should be exercised with only as much 
feedback to top management as they really want. 
Try not to take questions to management take 
solutions and take them only when there is a real 
reason to do so. 

Examples of key questions that the resources office 
needs to be ready to answer are; 

• Are we staying within our fund availability? 

• Do we have enough funding to get the job done? 

• Are there some areas where we have allocated 
more than we really need? 

• How much room do we have within our fund 
availability to expand our plan or to take on new 
work? 

• What are our problem areas and what are we 
doing about them? 

We need to be ready to go into detail, but I think the 
basic guideline is to tell management what it needs 
to know— not what you think would be interesting. 

The other types of reporting upward involve Review 
Authorities and Public Information. My basic 
ground rule is; ANSWER THE QUESTION ASKED. 
Don’t volunteer information not requested. Answer 
honestly and simply in a manner that is meaningful 
to the recipient. If, for policy or other reasons, you 
can’t give an honest answer, don’t answer at all. 
Better to take some guff for not answering than to 
destroy your reliability rating. One qualification is 
that so long as you are on the payroll, you must 
support the agency policy and decisions even if you 
don’t agree. The top management knows things you 
don’t know which may make their decisions the best 
possible under the circumstances. 


Characteristics of an Analyst 

What are the characteristics we look for and seek to 
develop in a budget or resources analyst? I think the 
main factors are; 

1. Reliability 

2. A "why” mentality 

3. A numbers sense 

4. Interest in the program and enough 
background to understand it 

5. Ability to work with others under stress 

6. Willingness to get involved in a lot of 
"spread-sheet” work 

7. A feeling for the big picture, even when 
working the detail 

8. Ability to express ideas, oral and written 

9. A sense of timing 

10. Common sense and sound judgment 

Reliability. This is probably the main qualification 
for any job. The person you are working for needs to 
know that you can be counted on for your best efforts 
and good judgment in carrying out any assignment. 

”Whv” Mentality . Whenever you are given 
information, there should be an automatic 
questioning of why this can or cannot be accepted at 
face value and how it relates to what you already 
know. The approach is not one of questioning 
integrity of the persons providing the information; 
but, in many cases, they will not have gone through 
this thinking process themselves. Before we can 
really use the information, we need to understand it. 

Numbers Sense . It is my observation that numbers 
talk to some people the way words do to others, 
good analyst needs a real feel for the numbers. I 
don’t know why some people seem to have this and 
others don’t, but I believe it is largely a matter ot 
habit, interest, and basic aptitude. 

Interest in the Program . To enjoy budgeting, you 
need a real feeling of identification with the program 
for which you are budgeting. As a minimum, you 
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need enough interest to acquire the basic knowledge 
to understand what you are budgeting for. Usually 
your effectiveness will increase in direct proportion 
to your real concern for accomplishing the objectives 
of the program. 

Ability to Work with Others You are always 
reliant on the work of other people. Sometimes our 
requests on others are somewhat unreasonable and 
have the potential of working against their interests. 
There is necessarily a good deal of stress involved in 
a budget operation, but success is dependent on 
ability to maintain a satisfactory rapport with the 
people with whom you need to work. I believe the 
main elements in this capability are: 

• Openness in letting them know what we are 
doing. 

• Giving them a sense of confidence on how we will 
use data, and 

• An ability to distinguish between friction that 
arises in business and your personal relationship 
with an individual. 

Detail Work . I believe that an analyst should 
actually enjoy a certain amount of spread-sheet 
work, even if it is partially automated. In my 
opinion, you need to work with the figures before 
they really become part of your thought processes. 

Big Picture . All of our detail work is done for a 
purpose. To be effective, you need to be able to keep 
the objective in mind even while you are working on 
the detail. You also need an ability to depart from 
the detail approach when the objective requires that 
you do so. You need to be prepared to accept the fact 
that those above you may reach conclusions which 
differ from the results of your detailed analysis. You 
need to realize that the detail work is only one input 
into a large arena of decision-making. 


Communication . For the results of our work to be 
effective, we need to express our ideas and 
conclusions both orally and in writing. We need to 


learn to express them in a way that will reach the 
person for whom they are intended. Often, the 
ability to put the message into a concise written form 
is a good test of your real understanding. The 
approach will differ with different people and at 
different levels of management. For the top level, we 
need to say what needs to be said briefly and clearly 
when the opportunity presents itself. 

Sense of Timing. This involves judgment as to 
which deadline needs to be met. It also means 
acceptance of the fact that a 70% job available a half- 
hour before a meeting is usually better than a 100% 
job a half-hour after the meeting. One of the most 
important aspects of providing support to 
management is providing it when needed. As an 
analyst, you need to be willing to take the risks 
involved in providing something less than a 
completely satisfactory product in time to do some 
pod. This is a matter of accepting the goals involved 
in the overall purpose of the work rather than taking 
particular pride in any individual piece of the total 
effort. 

C ommon Sense and Good Judgment A 

requirement for these characteristics is inherent in 
any responsible job. It is implied in all of the above 
points. The need for common sense and judgment 
becomes especially important when guidance is 
inadequate, when there is not enough time to meet 
all requirements, or when dealing with matters 
which have become emotional issues. In much of our 
work, all three of these factors are present. 

General Comment on QualiHcations 

No mention has been made on academic training. 
Over the years, I have worked with many excellent 
analysts, and I am not aware of any particular 
prrelation of specific types of education and success 
m budgeting. Some accounting and management 
courses are probably desirable, if not taken too 
seriously. In programs such as space or defense, 
some background in science and engineering can be 
helpful. Training in written and oral communication 
has value. In general, I believe successful 
performance in the academic and work environment 
is more important than any specific training. 


Programs, Projects, and Headaches 

by Homer Newell 

Former Chief Scientist, NASA 
(from his 1981 book Beyond the Atmosphere ) 


As with its predecessor, the National Advisory 
Committee for Aeronautics, NASA’s principal 
technical strength lay in the field centers. At the 
time of the metamorphosis into an aeronautics and 
space agency, N ACA had three principal centers, the 
Langley Aeronautical Laboratory near Hampton, 
Virginia; the Ames Aeronautical Laboratory at 
Moffett Field, California; and the Lewis Flight 
Propulsion Laboratory in Cleveland. In addition 
there was a High Speed Flight Station at Edwards 
Air Force Base in California and a small rocket test 
facility on the Virginia coast at Wallops Island. The 
first four of these became under NASA the Langley, 
Ames, Lewis, and Flight Research Centers, the 
research orientation of which Deputy Administrator 
Hugh Dryden was so desirous of protecting. Wallops 
Station was assigned primarily to the space science 
program. 

To the former NACA installations, NASA added six 
more: the Goddard Space Flight Center in Greenbelt, 
Maryland; the Jet Propulsion Laboratory in 
Pasadena; the John F. Kennedy Space Center at 
Merritt Island, Florida; the George C. Marshall 
Space Flight Center in Huntsville, Alabama; the 
Lyndon B. Johnson Space Center (which for many 
years was known as the Manned Spacecraft Center) 
in Houston; and, briefly, an Electronics Research 
Center in Cambridge, Massachusetts, which was 
transferred to the Department of Transportation. A 
sizable facility for testing large rocket engines was 
established in Mississippi not far from New Orleans 
and placed administratively under Marshall, which 
had prime responsibility for the Saturn launch 
vehicles used in the Apollo and Skylab programs. 
The Jet Propulsion Laboratory and Marshall were 
transferred to NASA from the Army; the others were 
created by NASA. As its original name suggests, 
Johnson was in charge of the Mercury, Gemini, and 
Apollo spacecraft and most of the research and 
development was related to those programs. 
Kennedy, originally the Launch Operations 


Directorate of Marshall, provided launch support 
services for both manned and unmanned programs, 
but the former required by far the greater capital 
investment and manpower. Both Goddard and the 
Jet Propulsion Laboratory were principal centers for 
the space science program, the former for scientific 
satellites, the latter for planetary probes. 

Management at headquarters guided the space 
program, directed the overall planning, developed 
and defended the budget for the agency, and fostered 
the kinds of external relations and general support 
that the space program needed. In a very real sense 
headquarters people labored at the center of action 
where the political decisions were made that 
permitted the space program to proceed. Yet the 
story of headquarters activity is mostly one of 
context, of background -essential, indispensable, but 
background nevertheless--against which the actual 
space program was conducted. Research, the essence 
of the space science program, was done by scientists 
at NASA centers, in universities, and at private and 
industrial laboratories. 

It follows that the mainstream of space science must 
be traced through the activities of these institutions. 
With occasional exceptions, like the upper 
atmospheric research of the Geophysical Research 
Corporation of America and the pioneering work of 
American Science and Engineering in x-ray 
astronomy, the contribution of industry was more to 
the development and flight of space hardware than to 
conducting scientific research. It remains, then, to 
take a look at the part played by the NASA centers. 

The principal space science centers were the Goddard 
Space Flight Center and the Jet Propulsion 
Laboratory (JPL being operated by California 
Institute of Technology under contract to NASA). 
Wallops Island, which for a time was placed 
administratively under Goddard, provided essential 
support to the sounding rocket and Scout launch 


vehicle programs. But not all NASA space science 
was done at these centers. The Ames Research 
Center managed the Pioneer Interplanetary probes 
and took the lead in space biology and exobiology— a 
term coined to denote the search for and 
investigation of extraterrestrial life or life-related 
processes. Langley had responsibility for the Lunar 
Orbiter and later the Viking Mars probe. Most 
notable was the lunar research fostered by Johnson 
in the early 1970s with the samples of the moon and 
other Apollo lunar data, which for a time made 
Houston a veritable Mecca for lunar scientists. But 
Apollo lunar science was an exception generated by 
the special nature of the manned lunar exploration 
program; and, generally, Dryden's policy stood in the 
way of more than a limited participation of the 
research centers in space projects. 

Over the years the NASA centers built up an 
enviable reputation of success on all fronts, in 
manned spaceflight, space applications, and space 
science. In the last mentioned, by 1970 Goddard had 
flown more than 1000 sounding rockets, more than 
40 Explorer satellites, 6 solar observatories, 6 
geophysical observatories, and 3 astronomical 
observatories, most of them successfully. In 
applications Goddard enjoyed comparable or better 
success rates with weather and communications 
satellites. The experience of the Jet Propulsion 
Laboratory was similar. By the end of the 1960s JPL 
had sent 3 Rangers and 5 Surveyors on successful 
missions to the moon and dispatched 5 Mariners to 
Mars and Venus. These achievements are bound to 
be recounted repeatedly and will rightfully be judged 
as success stories. Success, however, was not bought 
without a price of some mistakes, temporary failures, 
and occasionally severe personal conflict, which form 
an instructive part of the total history. In reviewing 
the struggles and problems that preceded the 
achievements, a proper sense of perspective is 
important, for troubles often tend to magnify 
themselves in the eye of the beholder. The 
difficulties were, after all, overcome in the ultimate 
successes that were achieved. Still, as part of the 
total story, perhaps as illustrating the natural and 
usual course of human undertakings, those 
difficulties are important to the historian. They 
should also be instructive to later managers. Thus, 
without at all deprecating their splendid 
achievements, it is appropriate to delve briefly into 
some of the trials endured by the Goddard Space 
Flight Center and the Jet Propulsion Laboratory. 


The Character of the Field Centers 

The different centers in NASA had distinctive 
personalities that one could sense in dealing with 
them. As might be expected the former NACA 
laboratories kept as NASA centers many of the 
characteristics they had acquired in their previous 
incarnation. One trait was the fierce organizational 
loyalty that had been displayed as part of NACA. 
Thus, while officials at those centers were convinced 
that the real power of the agency lay in the centers 
and felt very strongly that they should have some 
voice in formulating orders, and also that once given 
an assignment they should be left alone to carry it 
out, they also recognized that the ultimate authority 
lay in headquarters. Given marching orders, they 
would march much as ordered. 

The new centers in NASA had their difficulties in 
this regard, to varying degrees. The Marshall center 
reflected the background and personality of its 
leader, Wernher von Braun, and his team of German 
rocket experts. Bold, with a bulldog determination, 
undaunted by the sheer magnitude of a project like 
Saturn, they could hardly be deterred by request or 
by command from their plotted course. The efTort to 
superimpose the Juno space science launchings and 
the Centaur launch vehicle development on the 
Marshall team, when Saturn represented its real 
aspiration, simply did not work out. The Juno 
launchings had to be canceled after a string of dismal 
failures, which space science managers in 
headquarters felt was caused by lack of sufficient 
attention on the part of the center. Centaur, in the 
midst of congressional investigation into poor 
progress, was reassigned to the Lewis Research 
Center. The Manned Spacecraft Center developed an 
arrogance born of unbounded self-confidence and 
possession of a leading role in the nation's number- 
one space project, Apollo. A combination of self- 
assurance, the need to be meticulously careful in the 
development and operation of hardware for manned 
spaceflight, plus a general disinterest in the 
objectives of space science as the scientists saw them, 
led to extreme difficulties in working with the 
scientific community. But the art of being difficult 
was not confined to the manned spaceflight centers. 

In this both the Goddard Space Flight Center and the 
Jet Propulsion Laboratory were worthy competitors. 
So, too, was headquarters, for that matter. 

The Goddard Space Flight Center's collective 
personality stemmed from its space science origins. 
As the first new laboratory to be established by 


NASA, Goddard inherited most of the programs and 
activities of the International Geophysical Year, like 
the Vanguard satellite program and the Minitrack 
tracking and telemetering network. Also, many of 
the scientists and engineers of the Rocket and 
Satellite Research Panel and the IGY sounding 
rocket and scientific satellite programs joined 
Goddard to make up, along with the Vanguard team, 
the nucleus out of which the center developed. These 
origins indelibly stamped Goddard as a space science 
center, even though science accounted for only about 
one-third of the laboratory’s work (and by the nature 
of things, most of that effort went into the 
development, testing, and operation of sounding 
rockets, spacecraft, and space launch vehicles 
required for the scientific research). In actuality only 
a small fraction of the Goddard Space Flight Center s 
personnel was engaged in space science research. 
Nevertheless, the presence of those persons in key 
positions, which they came to fill as charter members 
of the laboratory, imparted to the center a character 
that accounted simultaneously for its success in 
space science and for many of the difficulties 
experienced with upper levels of management. 

As professional scientists, these persons were by 
training and experience accustomed to deciding for 
themselves what ought to be done in their 
researches. While subjecting themselves to a 
rigorous self-discipline required to accomplish their 
investigations, they nevertheless approached their 
work in a highly individualistic manner. They 
questioned everything, including orders from above. 
While they could and did work effectively as groups, 
their cooperation included a great deal of debate and 
free-wheeling exchange on what was best to do at 
each stage. To trained engineers in NASA-for whom 
a smoothly functioning team, accepting orders from 
the team leader as a matter of course, was the 
professional way of going about things--the 
seemingly casual approach of the Goddard scientists 
looked too undisciplined to work. 

The Goddard scientists had also been accustomed to 
determining their own objectives and pacing 
themselves as they thought best. The 
accomplishment of an experiment that produced 
significant new information was what counted; costs 
and schedules were secondary. That a project took 
longer to carry out than had originally been 
estimated was of little consequence so long as the 
project succeeded, particularly if the additional time 
was put to good use improving an experiment and 


ensuring success. This peculiarly science-related 
sociology of the space scientists at Goddard 
reinforced the tensions that naturally come into play 
between a headquarters and the field in large 
organizations, and led to a major confrontation in the 
mid-1960s. 

Field Versus Headquarters 

Headquarters and field in any effective and 
productive organization support each other, working 
as a team in the pursuit of common goals-those of 
the organization. Yet many aspects in even the most 
normal of headquarters-field relationships serve to 
pit one against the other at times. When 
circumstances exacerbate those normal centrifugal 
tendencies, serious trouble can arise. To understand 
the nature of the problem, a few words about the 
difference in headquarters and center jobs in a 
technical organization like NASA are in order 

At the heart of the difference is the matter of 
programs and projects. The raison d etre of an 
agency is reflected in its various programs, where the 
term program is used to mean a long-term, 
continuing endeavor to achieve an accepted set of 
goals and objectives. NASA’s overall program in 
space included the exploration of the moon and the 
planets, scientific investigations by means of rockets 
and spacecraft, and the development of ways of 
applying space methods to the solution of important 
practical problems. Each of these programs could be, 
and when convenient was, thought of as a complex of 
subprograms, such as a program to develop and put 
into use satellite meteorology, a program to improve 
communications by means of artificial satellites, or a 
program to investigate the nature of the cosmos. 
Barring an arbitrary decision to call a halt, one could 
foresee no reason why these programs, including the 
subprograms, should not continue indefinitely. 
Certainly, if past experience is a good indicator, the 
effort to understand the universe must continue to 
turn up new fundamental questions as fast as old 
ones are answered. As for exploration, the vastness 
of space, even of that relatively tiny portion of the 
universe occupied by the solar system, is so great 
that generations could visit planets and satellites 
and still leave most of the job undone. And it would 
be a long while before diminishing returns would call 
for an end to applications programs. 

Unlike a program, a project was thought of as of 
limited duration and scope, as, for example, the 
Explorer II project to measure gamma rays from the 


galaxy and intergalactic space. A program was 
carried out by a continuing series of projects, and at 
any given time the agency would be conducting a 
collection of projects designed to move the agency a 
number of steps toward the agency’s programmatic 
goals and objectives. The Explorer II project 
contributed to the programmatic objective of 
understanding the universe by determining an upper 
limit to the rate of production of gamma rays in 
intergalactic space, which eliminated one candidate 
version of the continuous creation theory of the 
universe. 

A project like a sounding rocket experiment might be 
aimed at only a single specific objective, last only a 
few months or a year, and cost but a few tens of 
thousands of dollars. Or a project could require a 
series of space launchings, many tens or even 
hundreds of millions of dollars, and take years to 
accomplish. The Lunar Orbiter, with five separate 
launchings to the moon, and the Mariner-Mars 
project that sent two spacecraft to Mars in 1971 were 
examples. Some projects were huge in every aspect, 
as was Apollo. In fact, because of its size and scope, 
Apollo was more often than not referred to as a 
program, although more properly Apollo should be 
thought of as a mammoth project which served 
several programs, among them the continuing 
development of a national manned spaceflight 
capability, the exploration of space, and the scientific 
investigation of the moon. 

With these definitions of program and project in 
mind, one can describe rather simply the difference 
between headquarters and center jobs. Headquarters 
was concerned primarily with the programmatic 
aspects of what NASA was up to, whereas the task of 
the centers was mainly to carry out the many projects 
that furthered the agency’s programs. The 
distinction is a valid but not a rigid one. 
Occasionally headquarters people participated in 
project work, but this was an exception to the general 
rule. The most notable exception was Apollo, the size 
and scope of which were such as to make the 
administrator feel that the uppermost levels of 
management for the project should be kept in 
Washington. Nevertheless, the prime task of 
headquarters, working with the centers and 
numerous outside advisors, was to put together the 
NASA program, to decide on the projects best 
designed at the moment to carry out the program and 
assign them to the appropriate centers for execution, 
and to foster the external relationships that would 
generate the necessary support for the programs and 


projects. As an essential concomitant to 
programming, much time was occupied in preparing 
budgets, selling them to the administration, and 
defending them before Congress. 

Also, each center, while project-oriented, had its 
center programs toward which the center directed its 
own short- and long-range planning. Thus, the 
research centers conducted programs of advancing 
aeronautical and space technology. In addition to a 
program of space science, the Goddard Space Flight 
Center pursued extensive programs of space 
applications and space tracking and data acquisition, 
with tracking and acquisition occupying almost 40 
percent of the center’s manpower. Unmanned 
investigation of the solar system was the Jet 
Propulsion Laboratory’s principal program. 

Although the qualifications should be kept in mind to 
have the correct picture, nevertheless the main 
distinction between the responsibilities of 
headquarters and those of the centers is clear. 
Center personnel members were primarily occupied 
with project work, while headquarters people spent - 
or should have spent--their time on program matters. 
That is where difficulties arose, for numerous 
pressures drove headquarters managers to get 
involved in project or project-related work. Such 
actions could only be regarded by a center as undue 
interference from above. 

Naturally, NASA space science managers were 
vitally interested in what was happening in the 
various space science projects. They were responsible 
for proper oversight. F3ut there was more to it than 
that; project work was where the action was. That 
was where interesting problems were being attacked 
and where exciting results were being obtained. 
Alongside project work, programmatic planning 
often seemed like onerous drudgery. As a 
consequence oversight tended to degenerate into 
meddling, to the distress of project managers and 
center directors. Even when headquarters managers 
took pains to couch their thoughts in the form of mere 
suggestions, their positions in headquarters made 
suggestions look more like orders. That program 
chiefs in headquarters occupied staff, not line, 
positions often was lost sight of in the shuffle, and 
some headquarters managers became adept at 
wielding what amounted in practice to line 
authority. 

To this natural tendency to get into the act were 
added the pressures of the job. As the NASA 
program grew in size, scope, and expense, upper 
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levels of management demanded more and more 
detail on schedules, costs, and technical problems. 
Nor was the demand for information confined to 
NASA management. Becoming increasingly 
familiar with the programs and their projects, the 
legislators also demanded what seemed an 
impossible amount of detail, either to provide while 
still getting the job done or for the Congress to 
assimilate. On the science side, members of the 
authorizing subcommittee in the House, under 
Chairman Joseph Karth of Minnesota, frequently 
concerned themselves with the details of engineering 
design decisions and were not loath to second-guess 
space project engineers on matters that seemed to 
NASA people to lie beyond the competence of the 
legislators to judge. An example of this searching 
interest was furnished by the investigation of the 
Centaur liquid-oxygen and liquid-hydrogen fueled 
rocket stage which Karth’s subcommittee undertook 
in 1962. NASA and contract engineers found it 
difficult to defend the propellant feed system which 
they had chosen and which could be shown to be most 
efficient for a rocket the size of Centaur, against a 
different system for which the committee expressed a 
preference and which admittedly would likely have 
more growth potential. 

Because of this increasing demand for information of 
various kinds, headquarters in turn demanded of the 
centers the detailed reporting that centers felt was 
appropriate for project managers but went far beyond 
what headquarters really needed. While program 
managers were willing to concede that the 
information they were calling for was more than they 
ought to need, yet they were caught in the middle; to 
do their jobs as circumstances were shaping them, 
they did need the data. They were forced, therefore, 
to insist, and the extensive reporting required, with 
its implied involvement of headquarters with what 
were strictly center responsibilities, remained as a 
continuing source of irritation. 

The irritation transferred to headquarters when 
centers were late or deficient in their reporting, 
especially when a center simply refused, sometimes 
through foot dragging, sometimes in open defiance, 
to supply the information requested. A center might 
be reluctant to respond when it felt that the request 
was premature, that the data were not yet properly 
developed, and that the center might later be called 
to task if the information supplied prematurely 
turned out to be incorrect. 

A related source of irritation arose in connection with 
the center's management process. At almost any 
time throughout the year a program manager might 


be called upon to furnish information about projects 
in the program. It was essential, therefore, to be 
continuously aware of the status of projects which 
might have to be reported. For this it was not enough 
to rely on written reports which came only so often. 
In addition, space science program managers kept in 
close touch with the project managers and attended 
many of the meetings held by the project managers 
with their staffs and with contractors’ 
representatives. This practice came to be a 
particularly sore point with the management of 
Goddard Space Flight Center. 

Strains on the Family Tie 

The Goddard Space Flight Center and NASA 
Headquarters, only half an hour’s drive apart, were 
connected by close ties. Between the two staffs, many 
personal associations dated from the days of the 
Rocket and Satellite Research Panel and the 
sounding rocket and satellite programs of the 
International Geophysical Year. An easy 
relationship existed from the very start of the center. 
John Townsend-who served as acting director of the 
center until the permanent director, Harry Goett, 
formerly of NACA’s Ames Aeronautical Laboratory, 
took over— had been associated with John Clark and 
the author at the Naval Research Laboratory. For 
many years Townsend had been the author’s deputy 
in the NRL’s Rocket Sonde Research Branch. Harry 
Goett and Eugene Wasielewski, whom Goett brought 
into Goddard as associate director, had long been 
acquainted with Abe Silverstein from the days of the 
National Advisory Committee for Aeronautics. 
These friendships served to mitigate the divisive 
forces between headquarters and field, but were not 
enough to avert an ultimate break. 

Harry Goett assumed the directorship of Goddard in 
September 1959. As was his nature he quickly 
entered personally into every aspect of the center’s 
work. From his first day until he left, he kept in close 
touch with every project. As an untiring battler for 
the center and his people, Goett endeared himself to 
his coworkers. He was a warm, emotional person 
who showed a deep interest in the men and women 
working for him, and on both sides a deep affection 
developed. 

In the first weeks and months of NASA's planning for 
its program, many center people had been drawn into 
headquarters working groups to help get things 
under way. But as center project work grew, these 
assignments, which tended to persist, began to 


interfere with center duties. Finding Goddard people 
still working on headquarters tasks a year after 
NASA's start, Harry Goett began to protest that his 
personnel should be relieved as fast as possible of 
these additional duties. On the other hand, center 
people’s taking part in headquarters planning was 
advantageous to the center. Both organizations tried 
to keep center participation within reasonable 
bounds. 

As Goett, Townsend, and their people built up 
Goddard and launched their initial projects, program 
managers were developing their own methods of 
keeping themselves and their superiors informed. 
Simultaneously the Congress was increasing its 
demand for detailed information, which it was 
incumbent on headquarters to supply. As the 
requirements for reporting increased, project 
managers complained that they were spending too 
much time with program managers and in preparing 
reports, time that would be better spent in getting on 
with the projects. In mounting crescendo, Goett 
complained to the author and his deputy in the 
headquarters space science office, Edgar M. 
Cortright, that headquarters managers were getting 
in the way of center management. Goett urged that 
headquarters people keep their hands off project 
management. 

While agreeing in principle with the Goddard 
director, Cortright and the author strove to get him 
to see that in the existing climate of continuing 
congressional scrutiny, keeping informed was an 
important part of headquarters work. That, space 
science management insisted, was an absolutely 
essential part of the program manager’s job, but not 
to usurp the project manager’s duties or to interfere 
with other work. Cortright and the author urged 
upon their people great care in working with the 
project managers to avoid any kinds of action that 
would undercut, or appear to undercut, the project 
manager’s responsibilities and authority. It was no 
advantage to the program for any project managers 
to feel that responsibilities had been in any way 
lifted from their shoulders. 

Headquarters was far from Simon pure in these 
matters, unfortunately, and there was considerable 
justice in Goett’s complaints. The natural urge to 
meddle plus the incessant pressure to keep informed 
led many program managers to get into the project 
business. Sometimes this led to strong adversary 
relations between program and project managers; at 
other times to close "buddy-buddy” relations. Both 


situations caused problems for center management 
and called for continuing attention. 

By the fall of 1962, Goett found the situation so 
disturbing that he felt impelled to complain openly at 
a NASA management meeting held at the Langley 
Research Center that headquarters got too much into 
projects and should stick to program management. 
His barbs were aimed not only at space science 
managers, but also at those responsible for 
applications programs and for tracking and data 
acquisition. He felt that there was not enough 
contact between the center director and the associate 
administrator. Goett also felt he did not have enough 
contact with the author. The last complaint stemmed 
from the mode of management the author had 
adopted, about which a few words are in order. 

Being a scientist, the author felt it wise to name as 
deputy an engineer whose training and experience 
would complement his own. Edgar M. Cortright, an 
aeronautical engineer with considerable research 
experience in the National Advisory Committee for 
Aeronautics, filled the bill very nicely. An 
implication of this philosophy of organization was 
that the deputy should be more than an understudy, 
more than just someone to sit in when the principal 
was away. Rather, the deputy should take 
responsibility for important aspects of the top 
management job that came within his sphere of 
expertise. This was the arrangement agreed on 
between Cortright and the author. Cortright would 
handle engineering matters, which meant oversight 
of much of the project work, dealing with contractors, 
and a great deal of the relations with the space 
science centers. The author would work on program 
planning, advisory committees, and most of the space 
science program’s external relations including those 
with the Academy of Sciences, the scientific 
community, and the universities. Such an 
arrangement had worked well at the Naval Research 
Laboratory, where John Townsend’s engineering and 
experimental bent had complemented the author’s 
theoretical background. Moreover, in addition to 
providing the top level of management in the office 
with talents and experience complementing those of 
the director, it was an effective way of providing a 
deputy with substantive work and to continue his 
professional growth. A deputy with nothing more to 
do than to wait around for the principal to be away 
must find life deadly dull, unrewarding, and 
stultifying. 

Under this arrangement, problems of the kind Goett 
was wrestling with would normally have been taken 
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up by Cortright. But Goett was not willing to deal 
with a deputy. As director of the Goddard Center- 
even though the author was meticulously careful to 
support agreements Cortright worked out--Goett felt 
that he should deal directly with the principal in the 
office for which the center was working. Under the 
circumstances the author took special pains to make 
it clear that he was available to Goett at any time, 
yet expressed the hope that Goett would work with 
Cortright in the normal course of day-to-day matters. 

The strain caused by the project-management versus 
program-management conflict took increasing 
amounts of time and attention. A great deal of the 
time spent with Goett was devoted to this problem. 
John Townsend, Goett’s man for space science 
matters, pointed out that if a program manager had 
only one project under way in his program, then it 
became very difficult to draw a line between program 
and project, and the pressure on the program 
manager to get into project management was 
overwhelming. Townsend recommended that 
programs be put together in such a way that a 
program manager would have several projects to deal 
with. Under such an arrangement a program 
manager could no longer give the single-minded 
attention required by a project, and should find it 
much easier to confine himself to program matters. 
Cortright and the author agreed and tried to avoid 
single-project programs. 

Goett pointed out that it was not just the cases in 
which program and project managers were at odds 
that gave trouble. When the two got along well 
together, often they would team up to promote their 
project over other projects which the center 
management--taking into account existing 
constraints on dollars, manpower, and facilities- 
might judge to be more appropriate. Thus, program 
and project managers working hand in glove for their 
own projects-perhaps to enlarge them or to extend 
them beyond existing commitments-were not always 
working for the best interests of the center 

Goett was most disturbed to have program managers, 
in the name of keeping in touch, attend meetings 
with outside contractors. Even if the headquarters 
people came with the determination to keep their 
mouths shut, contractors’ representatives had a 
penchant for tossing questions to the headquarters 
representatives, with the implication that that was 
where the final word would lie. And when 
headquarters people did volunteer comments, their 
comments tended to take on more weight than the 
word of the project manager. These difficulties 
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technically more competent than the project 
manager— which Goett didn’t feel could happen very 
often. In that case the project manager tended to 
defer to the headquarters person for decisions and 
recommendations that the project manager should 
make personally, and the contractors were easily 
confused as to who was calling the shots. 

Goett’s solution to these problems would have been to 
keep program managers away from project 
management meetings, and especially away from 
meeting with contractors. Considering the prograni 
manager’s basic responsibility to see to the health of 
the program and the corresponding need to keep 
informed-a need that was enhanced by the growing 
amount of attention given by congressional 
committees to NASA’s programs and projects- 
Goett’s solution was not acceptable. Cortright and 
the author spent a great deal of time trying to get 
Goett to appreciate headquarters’ needs and to agree 
to some middle-of-the-road way out of the dilemma, 

A written description was prepared of the distinction 
between program management and project 
management, and the author committed himself to 
ensuring that the program people understood the 
bounds of their authorities and responsibilities. But 
the author also insisted that the way be kept open for 
headquarters people to keep adequately informed. 
Goett was not satisfied. In a letter to Associate 
Administrator Robert C. Seamans 5 .July 1963, he 
outlined some of the problems as he saw them^ 
Shortly thereafter, on 26 July 1963, the Office o 
Space Science and Applications proposed a revision of 
NASA Management Instruction 37-1-1. In Appendix 
A were specific definitions of program and project. 
The instruction made the point that the 
headquarters job concerned itself with program 
matters primarily, while project managers normal y 
were at field centers. On 5 November 1963 the 
author wrote Harry Goett on the subject of 
headquarters-center relations. The letter outlined 
agreements that it was hoped had been reached to 
keep headquarters people properly informed, without 
undercutting the center’s position with contractors. 
But matters continued to deteriorate. 

Complaints were not confined to the center side. In a 
talk given to a number of managers of space science 
and applications projects, at Airlie House near 
Warrenton, Virginia, the author spoke on relations 
between program managers in headquarters and 
project managers in the centers. By giving what was 
viewed by headquarters people ds too much emphasis 
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to the rights and prerogatives of project managers, 
the author drew forth some howls from the former. 
On 30 December 1963 the staff of the OfTice of Space 
Science and Applications met to discuss relations 
with the Goddard Space Flight Center. Program 
people complained that Goddard seemed to be waging 
a war to keep headquarters at arm’s length. It was 
difficult to find out about contractor meetings in time 
to attend. Although Goett had stated that 
headquarters should keep itself informed by means of 
the reports it received, still Goddard habitually did 
not turn in reports on time. The center was being too 
independent in formulating its plans for supporting 
research; i.e., the general background research of the 
kind all centers undertook in support of their project 
work. Program chiefs felt a need to specify reporting 
requirements for this supporting research, since most 
of the money for such research came from portions of 
the budget for which the program chiefs had 
responsibility. Another complaint concerned 
Requests for Proposals, documents which centers 
sent to potential contractors asking for bids on work 
that the center wanted done. Program people were 
required to follow the progress of such RFPs through 
the headquarters paper mill and to assist in 
expediting their progress. It was important, 
therefore, for them to keep in close touch with the 
formulation of the work statements that would go 
into the Requests for Proposals. Yet the center 
appeared to be making it difficult for the program 
managers to keep in touch. The Interplanetary 
Monitoring Platform project was considered an 
illustration of the center’s intentions in this regard. 
Since a decision that program people would attend 
"working group" meetings of projects, Paul Butler, 
manager of the IMP project, had ceased to hold 
working group meetings. Instead he held what he 
called coordination meetings” with his staff, which 
headquarters people were explicitly told they were 
expected not to attend. 

While the managers in the Office of Space Science 
and Applications were most intimately involved in 
the day-to-day relations with the center, the 
problems also had the continuing attention of Webb, 
nnd Seamans. Concerned about overruns 
and schedule slips in NASA projects, the 
Administrator’s Office noted that many of the bad 
examples were Goddard’s. As general manager of the 
agency, Associate Administrator Seamans 
maintained pressure on the Office of Space Science 
and Applications to correct the deficiencies. 
Although Seamans had known and worked with 
Garry Goett since 1948 and admired him very much. 


Seamans could not accept Goett’s insistence that 
headquarters leave Goddard to its own devices. As 
Seamans wrote years later; 

... it was essential if NASA was to continue to 
receive Congressional support, that we tighten 
the management of our projects in order to keep 
costs and schedules closer to plan. We could not, 
in the public interest, take it on faith that Harry 
Goett was doing all that could be done to manage 
these projects properly. It was necessary for 
NASA Headquarters to have direct access to a 
variety of management data as was the case with 
other NASA centers. I kept Dr. Dryden and Mr. 
Webb fully informed of the 
Headquarters/Goddard relationships and of 
important issues. 

But the problems did not end. Discussions with 
Goddard management seemed to elicit too much 
explanation of why it was in the nature of things for 
schedules to slip and not enough desire to change 
matters. The Goddard scientists especially could not 
see why there should be any urgency about adhering 
to a schedule if additional work would produce a 
better experiment. As for the experiments, usually 
there was no reason why they should be done now 
rather than later, unless of course, they had to be 
timed to coincide with some natural event. But 
NASA’s record of doing what it said it would do on 
time and within cost was important to those who had 
to fight for the agency’s appropriations. Schedules 
and costs were most visible to a carefully watchful 
Congress, and for years NASA continued to feel that 
it had to sell itself. Besides, it was just plain good 
management to estimate costs and schedules 
correctly and then keep to those estimates. 

Whatever opinion the Administrator’s Office might 
have had as to who was the more to blame for the 
strains caused by projects versus programs, the 
apparent unresponsiveness of the center on 
tightening up project management overshadowed the 
other concerns. Both Associate Administrator 
Robert Seamans and his deputy, Earl Hilburn, 
pressed continually for better performance. But 
when, in a stressful meeting with Seamans, Goett 
took such a rigid position that he left no 
maneuvering room for headquarters, the associate 
administrator decided that Goett had to go. With the 
concurrence of both Webb and Dryden, on 22 July 
1965 Seamans removed Goett from the directorship 
and replaced him with Dr. John F. Clark, who had 
been chief scientist in the Office of Space Science and 
Applications. 




It was a traumatic experience for Harry Goett and for 
others. The author found it a most unpleasant duty 
to go out to the Goddard Space Flight Center to meet 
with key managers and inform them that their 
director was being replaced. Goett was beloved of his 
people; he had been a conscientious, hard-working, 
imaginative director, under whose regime the center 
had achieved most of the space accomplishments of 
NASA’s first few years. Goett himself had played a 
key role in establishing a productive relationship 
with the academic community. Those 
accomplishments were, of course, the real story of the 
Goddard Space Flight Center, not the struggles over 
how to manage. It was tragic that Goett’s obsession 
over one concept of headquarters-field relationships-- 
born perhaps of his past experience in the NACA - 
made him unable to appreciate the new climate in 
which NASA had to operate. It was unfortunate that 
the author was unable to work out some 
accommodation that would have kept Goett at the 
Goddard helm. Harry Goett’s departure was a 
distinct loss to NASA. 


Not having Goett’s flair for the controversial, John 
Clark projected a more pedestrian image for the 
center. Yet under his administration, Goddard 
continued its record of successful space science and 
applications flights. The problems remained, and 
both center and headquarters had to work 
continuously to keep them under control. But both 
sides approached the problems with a better 
understanding of each other’s needs. In short order 
Clark was telling headquarters where to head in, and 
headquarters was pressing him to get on with the job 
of better resource and schedule management. 

The difficulties experienced by the Office of Space 
Science and Applications with the Goddard Space 
Flight Center occurred in various forms and varying 
degrees with all the other centers. The task of 
finding ways for headquarters and field to work 
together harmoniously and effectively is never 
ending Nor is it to be expected that tension between 
headquarters and field will ever disappear. Should 
this happen, one or the other will probably not be 
doing its best job. 
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Evolution of a Technical 
Management Organization 

by Thomas J. Lee 

Deputy Director. Marshall Space Flight Center 
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Sna . h '-as to optimize the 

Spacelab configuration to provide a feasible system 

Tf theTr""" "^P^bility for the user. The output 

orbL " preliminary 

orbiter interface document, (2) preliminary U S 

user requirements which were later integrated with 

La3h" '"T and (3) preliminary 

Spacelab system specifications. With these NASA 

had a good understanding of the program 
requirements and a skeleton manageLn" 
organization at MSFC and Headquarters This 
ear y program understanding proved to be 
agr^rto^ through the entire program. When ESA 
g d to participate in the program in 1973 tho 
resulfo of Spacelab-relatoS sLdy e?fo,fo we,: 
p vi e directly to the Europeans. MSFC 

order to concentrate the available manpower 
resources on working with ESA and its contraLrs. 

fnTd'ef.-r in Spacelab planning 

laT'e^S^ ^rylab.^anduTlo^fhiTto^ 

de^elprerraX'M^^^^^^^^^ 

center for Spacelab Program manage^^t 

At the beginning of the program the nolii.v.i 
p anning phase was to some people on both sides of 


38 



the ocean as important to program success as 
program technical definition. It is not the intent 
here to downplay that importance. On the contrary, 
it proved during implementation and operation to 
be vital. This planning culminated in two very 
significant documents: (1) a Memorandum of 

Understanding (MOU) signed by the respective 
heads of NASA and the European Launch 
Development Organization (ELDO), later renamed 
the European Space Agency, and (2) a country-to- 
country agreement approved by the 
Department and a representative of the lU 
participating European countries. 

It was evident that considerable thought and time 
were spent to make the MOU clear, concise, and 
easy to understand, yet general enough to allow the 
implementers flexibility to complete the program 
without the need to exercise the disputes clause. In 
fact, the document was so well written that during 
the development program there was never a 
disagreement sufficient to warrant changing the 
document. 


IMPLEMENTATION 

With such detailed planning, the implementation 
and development phases would appear to be 
relatively straightforward. In most programs, a 
high degree of early planning will minimize the 
problems commonly found in schedules, cost and 
performance during the development phase. This 
was true in Spacelab; however, a new set of 
variables was introduced in working with the 
Europeans. First, their industry did not have in 
place boilerplate standards and specifications tor 
manned systems; these had to be developed. 
Second, ESA had to translate NASA requirements 
and specifications into its documentation system 
which resulted in a pyramid of very lin'd 
controlling documents, some of which required joint 
signatures by NASA and ESA. One of the more 
complex was the Interface Control Document (1C 
for Spacelab and the orbiter, requiring approval by 
NASA ESA and the prime contractors for both 
Spacelab and the orbiter. The complexity was 
compounded by the Spacelab’s dependence on the 
orbiter for accommodations and the fact that the 
two programs were being developed in parallel. 


MSEC’S early detailed planning revealed the 
requirement for considerable NASA resources to 
perform the technical evaluation and monitoring 
necessary to ensure that the overall system 


requirements and specifications were met, and to 
perform the operations development planning at 
KSC, JSC, and MSFC. It came as a surprise to 
MSEC management when, early in the program 
the NASA Administrator questioned the level ol 
effort required by NASA civil servants to 
technically evaluate and operate what was 
concluded to be a free Spacelab. 


NASA found itself in unfamiliar waters in working 
with the Europeans, for whom a standard mode ol 
operation is to develop systems through multi- 
national involvement. The key features of this 
mode are the geographical distribution of funds o 
each contributing country in an amount comparable 
to that pledged to the program and the introduction 
of the prime contractor and co-contractor rather 
than subcontractor relationships. These features 
were new to NASA but not to ESA, and the 
anticipated shortcoming, i.e., the inability to selec 
the most competent subsystem contractor from each 
country, was only a short-range concern. Until the 
program had progressed beyond the critical design 
reviews, and subsystem and component 
development was well under way, there was a 
constant concern that ESA lacked the technical 
depth and breadth to manage such a larp 
undertaking. MSFC, however, took comfort in the 
fact that an experience base did reside within 
NASA and that the ESA management team was 
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If one area had to be identified as a significant 
concern resulting from NASA’s lack of familiarity 
with the ESA technical management system, it 
would be the assurance that top level specifications 
and requirements flowed from the prime contractor 
to the co-contractor and ultimately to the vendors 
and suppliers. This included traceability to indicate 
how and if the requirements and specifications were 
met. This became a real concern late in the 
program, when adequate recorded evidence o 
successful completion of qualification and 
acceptance testing was sometimes lacking. 1 here 
was no question on the part of NASA engineers, 
who had worked closely with ESA and its 
contractors, that the qualification testing had taken 
place; it was simply a matter of formally 
documenting the data. This problem came about 
because no contractual requirements for forrflal 
documentation were placed on the co-contractor by 
the prime contractor. 


One of the first management decisions the Spacelab 
Program Office made was to maintain heavy Mbf U 
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engineering involvement from the beginning to the 
end of the program. This involvement was used to 
generate and approve all technical requirements in 
a way that the engineers felt accountable for the 
technical performance of the Spacelab system even 
though the overall responsibility resided with the 
program manager. With the e.xception of 
propulsion, all MSFC technical disciplines were 
involved. 


OPERATION 

When the time came to provide the manpower 
resources, there were three alternatives; (1) utilize 
civil servants, (2) contract with a European 
contractor, or (3) contract with a U.S. aerospace 
firm. Using civil servants was not practical 
Contracting with the European Spacelab contractor 
clearly had positive points; however, when long- 
term cost implications of retaining a foreign 
contractor in this country, not to mention that the 
only past experience in the required mission 
integration and launch operations resided in this 
country, the decision to contract with the U S 
aerospace industry came easily. The contract was 
written with two schedules, one to include launch 
operations and integration activities managed by 
KSC, and the sustaining engineering and hardware 
control administered by MSEC. The intent of the 
latter schedule was to phase down the MSFC civil 
service personnel from a peak during the 
development phase as the contractor came on board 
and the operations were well defined This was 
accomplished as planned. The program was well 
into development when it was recognized that an 
organizational interface with the user community 
independent of the program office responsible for 
the design and development should be established 
at MSFC. This organization (Payload Project) 
would ensure that the user requirements were 
properly considered and ultimately satisfied where 
practical. The new organization reported to the 
center director, as did the Spacelab Program Office, 
and assumed the very significant role of payload 
mission planning and experiment analytical and 
physical integration. The efforts of this 
organization led to the establishment of the payload 
and mission specialists training facility and the 
Payload Operations Control Center (POCC) at 
MSFC. The Spacelab payload mission successes can 
be attributed more to this organization than to any 
other single organization in NASA. This 
organization and mode of operation will be used as a 
model for the Space Station Freedom Program. 


CONCLUSION 

MSFC s approach to project management and 
organizations has changed over the years, first to 
develop a project management capability and then 
to adapt to multiple projects utilizing a matrix 
approach. The center weathered this to become a 
very competent well-balanced research and 
development organization with flexibility to adjust 
to the nation’s future space policy. 

Building and maintaining such an organization 
demands the constant attention of the entire 
management structure. Even though it is not 
practical or feasible to establish a detailed set of 
standards and procedures to be used by each 
manager and supervisor, there are a number of 
common groundrules which allow any organization 
to function efficiently and effectively. The following 
are a few of the more important groundrules that 
have proven to be helpful to MSFC: 

(1) Emphasize the planning phase as the most 
important part of any program. The more 
detailed the program plan, the better it is 
understood, and the more likely it is to be 
successful. Proper organizational placement and 
competence levels are essential. 

(2) Develop and maintain an in house technical 
capability through the careful selection of in 
house projects and the recognition of the skills 
required for future programs. 

(3) Establish a good understanding with 
Headquarters concerning what is expected of the 
Center. This should be done on a project-by- 
project basis. 

(4) Require substantial involvement by the 
technical discipline from the planning phase 
through development and operation, but ensure 
that overall program responsibility (cost, 
schedule and performance) remains with the 
program or project manager. 

(5) Establish a Center strategic plan which is 
understandable, realistic, and communicates to 
every person at the Center his or her respective 
role. 

To manage a complex technical program through a 
matrix organization with involvement from other 
development and/or operation centers demands 
constant attention to detail and involvement by all 
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levels of center management. The concept of arm- 
chair management, where the majority of the 
manager’s time is spent in the management 


information control center concerning himself or 
herself only with cost and schedule, has not been 
acceptable in the past nor is it an acceptable mode 
for the future of N ASA. 
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The Program and Project Management Training 
and Development Initiative 


by M. Peralta 

NASA Associate Administrator for Management 


After the Challenger accident, a study team headed 
by General Sam Phillips conducted an assessment of 
NASA’s management practices. The team, known as 
the NASA Management Study Group, conducted its 
review and prepared a report for the Administrator. 
A major recommendation was that NASA "'institute 
formal training and development program(s) for 
program/project managers.” 

This recommendation confirmed a similar one that 
came from two project management workshops 
conducted in 1975. That recommendation resulted in 
the development of the Project Management Shared 
Experiences Program (PMSEP). The one-week 
PMSEP is an excellent interactive seminar, but it is 
limited in size and scope and cannot fulfill all of the 
agency’s requirements. 

The first step in implementing the Study Group’s 
recommendation was to conduct an in-house 
requirements and feasibility study. This study, 
completed in October 1987, reached the following 
conclusions. First, the management of NASA 
programs and projects is becoming increasingly 
complex, and the demand for trained and experienced 
personnel is increasing as the available pool is being 
depleted. Second, in addition to our traditional 
programs and projects, we now have training and 
development requirements for people involved in 
research, facilities, and information systems 
activities that must be managed as projects. And 
last, the total population contained in these groups is 
approximately one-third of the NASA civil service 
workforce. 

To assist in developing NASA user requirements, the 
study manager relied heavily on the project 
management knowledge, skills, and experience data 
developed at a Program and Project Management 
colloquium held at Wallops Flight Center in 1980. In 


addition to this most valuable data, interviews were 
conducted and a questionnaire was administered to 
approximately 125 NASA employees attending 
agency development programs. 

At the same time, we looked at what industry and the 
Department of Defense were doing. We collected in- 
depth information from 11 aerospace and non- 
aerospace companies. We visited the Defense 
Systems Management School at Ft. Belvoir, Va., and 
also examined the many other excellent DoD 
programs. In brief, we found the following: 

• There are no quick fixes or magic bullets. 

• There is a concentration on on-the-job training 
combined with formal training. 

• Advanced degrees are common and frequently 
encouraged. 

• Time in training varies from weeks to years. 

• Contractors and universities are frequently 
used to design, develop, and deliver training 
programs. 

• The average time in the project management 
cycle, from entrance to project manager, is 
about 15 years. 

• There are similarities in curriculum content. 

• There are a number of readily available 
project management training sources on the 
market; however, they vary widely in 
applicability and quality. 

We completed our study with a look at several 
university degree programs and an examination of 
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what field centers were doing to train program and 
project management personnel. Although many 
centers offer short-term training opportunities, there 
is no comprehensive, requirements-driven program 
in place in NASA. 

All of these findings were reported to the NASA 
Program Project Management Steering Group. This 
group, established in 1984, consists of members from 
the field centers and Headquarters program offices 
who have broad knowledge and experience in 
program and project management. The Group assists 
NASA management by providing a focus, although 
somewhat limited, for this most important function. 
The group has been active in reestablishing the 
Project Management Shared Experiences Program, 
has provided input to the Phillips Study Group, and 
advises management on appropriate NASA 
Management Instructions (NMIs). 

The Steering Group accepted the study findings and 
tasked the study manager with developing a NASA 
training and development model complete with 


curriculum. A working group of the committee was 
appointed to assist. After three iterations, we have 
agreement on the model shown below. 

Some important features of this model are: 

• A commitment to training and 
development at any point in the cycle 

• A partnership between the field centers and 
NASA Headquarters in the design and 
delivery of core curriculum 

• Where practical, informal career paths and 
development plans will be used 

• Training consists of knowledge and skills 

• A modular design will be employed 

• An employee may enter or exit the cycle at 
any appropriate level 


PROGRAM/PROJECT MANAGEMENT INITIATIVE 
NASA MODEL FOR DEVELOPMENT AND TRAINING OF PROJECT 

MANAGEMENT PERSONNEL 


RETURN TO RETURN TO 

CONTINUES IN TECHNICAL TECHNICAL 

TECHNICAL SPECIALTY OR SPECIALTY OR 

SPEOALTY MANAGEMENT MANAGEMENT 



i i 

i i 

L 


mm 

BASIC 
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1 1 

1 1 
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1 1 

1 1 
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CENTER SPECIFIC 
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OJT 

OJT 
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• ORIENTATION 

• TECHNICAL 
CMSOPUNE 
DEVELOPMENT 

• PERSONAL SKILLS 

• PERFORMANCE 
IMPROVEMENT PLAN 

• CAREER POSSIBIUT1ES 


• TASK PLANNING 

• BASIC PROCUREMENT 

• BASIC BUDGETING 

• TECHNICAL 
MANAGEMENT 

• SEB PROCESSES 

• BASIC PERSONNEL 


• PROJECT PLANNING 

• SELECTING 
CONTRACTORS 

• BUSINESS 
MANAGEMENT 

• TECHNICAL 
MANAGEMENT 

• SEB PROCESSES 

• LEADERSHIP AND 
PERSONNEL 
MANAGEMENT 


• PROJECT PLANNING 

• MULTICENTER 

• INTERNATIONAL PARTIOPATION 

• SELECTING CONTRACTORS 

- NEGOTIATIONS 

- INCENTIVES 

• MANAGING COMPLEX BUSINESS ISSUES 

• SEB PROCESSES 

• MANAGING MANAGERS 

• CONGRESSIONAL PROCEDURES 

• BUDGET CYCLE 
. RELATIONSHIPS 


PROCESS 


PROCESS 


PROCESS 


PROCESS 

• INSTRUCTIONAL 
TELEVISION 

• ON/OFF CENTER 
KNOWLEDGE/SKILLS 
INSTRUCTION 


• CASE STUDIES 

* RESIDENT TRAINING 

• SHARED EXPERIENCE 

• LESSONS LEARNED 

• RESIDENT TRAINING 

• SHARED EXPERIENCE 

• LESSONS LEARNED 

• WORKSHOPS 

• ANNUAL MEETING 
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The working group also spent much time developing 
the core curriculum for the Advanced Project 
Management Course. It was decided to concentrate 
on this level due to a pressing need in this area. The 
core curriculum includes program/project planning, 
business management, technical management, 
acquisition reviews, and lessons learned. The first 
ofTering of the Advanced Project Management Course 
occurred in October 1988. Pilot courses in systems 
engineering and program control were offered this 
past summer. 

In addition to training courses, a number of related 
activities were also undertaken. It is widely agreed 
that we must build on our past experience in 
managing programs and projects. To do this we must 
collect and disseminate the lessons learned and 
shared experience of past and present management 
teams. A pilot lessons-learned videotape is presently 
being prepared. Using the "lessons learned” from 
this pilot, we hope, with the cooperation of the NASA 
Alumni League, to document our experiences from 


Apollo to the present. We also plan to use live 
interactive television productions to deliver issues of 
interest to our program and project management 
workforce. We will soon establish a pilot computer 
network that will give us the potential for electronic 
mentoring. This publication, Issues in NASA 
Program and Project Management , is a direct result 
of our intention to capture and pass on our heritage 
and culture in the hope that some of this information 
will be of direct and immediate benefit to our 
workforce. 

Our workforce is key to the agency's success, and this 
requires a highly motivated and competent staff. 
This is particularly challenging today because of the 
growing complexity of the agency's activities. As a 
result of the program/project management initiative, 
the agency has underscored its commitment to 
providing the very best training and development for 
our program and project workforce as well as 
providing them with the tools they need to meet the 
future challenges associated with the NASA mission. 
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Weekly Online Update Tool for Managers 

Did you know that there is a weekly current 
awareness service entitled Managers on 
NASA/RECON? Are you interested in new 
developments in space commercialization, 
Congressional and legislative reports, new business 
methods and trends, research and development 
programs, and many more timely subjects? 

Every Monday morning a list of twenty citations 
(including books) is compiled. Items of interest to 
managers and administrators of NASA 
Headquarters, NASA Centers, and NASA 
Contractors are selected for pertinence to NASA s 
mission, management, and foreign technology 
exchange. 

Any NASA/RECON user may utilize the service by 
executing the Managers stored search from within 
File Collections A, B, D, N, O, and P , as follows: 

QUERY EXECUTE MANAGERS (NAHQ). 

Once the stored search has ceased execution, simply 
use the DISPLAY, BROWSE, or TYPE command to 
review the results. 

Some of the subject areas covered by the weekly 
service are: 

• Current aerospace technology on present and 
future NASA space missions, including 
aerospace medicine. 

• Technologies of the European space programs as 
well as those of the U.S.S.R. and Japan. 

• New management methods, business trends, and 
policies concerning procurement, financial, 
contract, personnel, and research management. 

PACE O 


• Congressional and legislative reports. Federal 
budgets, and appropriations of the NASA 
programs. 

• New developments in database management 
systems. 

• Current reports on international trade, market 
research, and economics. 

• Current research in artificial intelligence, expert 
systems, and robotic technology. 

• Current technology transfer, assessment, and 
utilization. 

• Current reports on international relations, 
cooperation, and space law. 

Project Management: A Systems Approach to 

Planning. Scheduling, and Controlling , second 
edition, by Harold Kerzner, 1984. Van Nostrand 
Reinhold Co., New York. 

Since his first edition just 10 years ago. Dr. Kerzner, 
a professor of systems management at Balwin- 
Wallace College and president of Cleveland-based 
Project Management Associates consulting firm, has 
expanded his college-level textbook to 937 pages. As 
a textbook, it contains a couple of final exams 
(multiple choice), 332 discussion questions, and 42 
case studies. As a resource for managers and 
executives, it suffers from a thin and faulty index, 
making it difficult to look up needed information 
quickly. Nevertheless, the book is of value to those 
who desire a lengthy and broad overview of project 
management, as well as useful tips and ideas for 
management problem-solving. It is the leading book 
in a narrow field. 

/ANA r *AL-lviED 
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While NASA defines a program as a related series of 
efforts which continue over a long period of time, 
designed to pursue a broad scientific or technical 
goal, and a project as a defined, time-limited activity 
with clearly established objectives and boundary 
conditions executed to gain knowledge, create a 
capability or provide a service-this book uses the 
terms interchangeably in the index and rarely 
mentions program management in the text. Instead, 
the author creates a hierarchy of line managers who 
answer to the project manager who in turn answers 
to a functional manager or executive. Thus, his gag 
definition; "Project management is the art of 
creating the illusion that any outcome is the result of 
a series of predetermined, deliberate acts when, in 
fact, it was dumb luck.” 

Dr. Kerzner traces the concept of project 
management to its birth in the 1960s in aerospace, 
defense and construction, maintaining that the 
concept took off in the early 1980s and is the wave of 
the future in management techniques. Complexity 
and diversity set in during the late 1960s, forcing 
some companies to accept project management 
reluctantly. However, the real breakthrough came 
in 1970 when "NASA and the Department of Defense 
’forced' subcontractors into accepting project 
management.” 

Likewise, the textbook is built around systems 
theory as opposed to other traditional or more 
conventional management theory. Management-by- 
objectives, for examples, places too much emphasis 
on the end item or goal, with little regard for people. 
Behavioral theory emphasizes human relations 
(person and job) or social relations (cultural 
relationships which involve social change). Decision 
theory, on the other hand, is too rational, using 
mathematical or scientific models. The empirical 
school of thought emphasizes the study of 
experiences of other managers, but all too often, 
situations are not similar. That leaves systems 
theory, which, in this text, is part and parcel of 
project management. 

"Project management utilizes the systems approach 
to management by having functional personnel (the 
vertical hierarchy) assigned to a specific project (the 
horizontal hierarchy),” Dr. Kerzner says in his 
definition which guides the text. The systems 
approach is not clearly defined, roughly "a group of 
elements (that) can act as a whole toward achieving 
some common goal, objective, or end.” More 
specifically, one of the hundreds of charts in the text 


indicates that the systems approach starts with an 
objective shaped by constraints, which is broken into 
requirements and then alternatives, leading to trade- 
offs (in terms of cost, time, performance or policy). 

The first attempts to mark the boundaries of systems, 
programs and projects are attributed to the U.S. Air 
Force and NASA, but the text does not cite sources or 
indicate when such distinctions were made. 
Essentially, the text views project management as a 
"coordinative” function and matrix management as a 
"collaborative” function. Problems result when there 
is dual accountability between project manager and 
functional manager, and when there is a difference of 
opinion. Thus, in a matrix organization, the project 
manager "must continually negotiate,” calling for 
interpersonal and communication skills. 

The book does seem to indicate that a modified 
matrix organization is superior to both a pure 
functional structure and a pure product 
organizational structure, especially for labor- 
intensive projects, but not capital-intensive ones. 

Project management does have a downside, the 
author notes. The main risk, observed in missile and 
space programs, is falling in love more with job than 
family. You know if you are to the edge if you take 
work home or on vacation. You know if you are over 
the edge if you consider 5 p.m. as the working day 
half over, or if you come in Friday and realize there 
are only two more working days until Monday.--- 
WML 

Project Management Handbook , edited by David I. 
Cleland and William R. King, 1983. Von Nostrand 
Reinhold Co., New York. 

Although this "handbook” bills itself variously as a 
reference guide and how-to manual, it is really a 
collection of articles clustered around certain themes 
such as life cycle management and project planning. 

Most of the 35 articles come from college professors of 
management, and more from the University of 
Pittsburgh than any other college. David Cleland is 
a professor of engineering management there, and 
William King is a professor of business 
administration there also. Five articles are co- 
authored, including one by Cleland and King on 
linear responsibility charts. 

Two of the best articles in this book are from Fred 
Holenbach of the Bechtel Power Company. In one, he 
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discusses project control at Bechtel in a no-nonsense, 
step-by-step manner. In the other, he outlines the 
advantages and disadvantages of the matrix 
approach, concluding simply: "The success of a 

project manager is measured by client satisfaction as 
a result of getting the job done on time and within 
budget.” 

Other articles, especially from the academics, are 
more esoteric. Readers who do not understand 
stochastic network analysis or cultural ambience 
may not even attempt articles with such terms in the 
titles. Technical terms and complex charts abound in 
this book which claims to be more pragmatic than 
theoretical. 

Admittedly missing in this "handbook” are chapters 
on configuration management and value 
engineering, which the editors describe as parochial 
interests,” yet regarded as important in the 
aerospace industry. 

In 724 pages, only four references to NASA are listed 
in the index, most of them clustered in a section 
called "The Successful Application of Project 
Management.” One article in this section seems to be 
based upon a 1974 study by Murphy, Baker and 
Fisher on "Determinants of Project Success,” 
sponsored by NASA (NCR 22-03-028). Actually, 
there are other references to NASA in this book, 
despite the index. The very first chapter, for 
example, tells how General Phillips came into the 
Apollo Program in 1963 and created one of the first 
successful matrix organizations, with 120 persons at 
the headquarters program office managing upwards 
of 30,000 persons in three Centers. NASA life-cycle 
management is discussed near the middle of the 
book. Twice, NASA studies are cited in an article at 
the end of the book, but not indexed. More so than 
other books, reference books need to be fully and 
accurately indexed for users as a reader service. 

One of the liveliest pieces in the handbook is by Dr. 
Thomas E. Miller of the University of Missouri- 
Kansas City. Although it focuses on managing 
change in a fire department, the article describes 
four natural groups seen around any office. There 
are the technical-specialist organizational types who 
tend to be productive but standoffish. The social- 
specialist regulars are outgoing, popular and 
accepted by everyone except top management. Then 
there are the "underchosen” who are loved by 
management but who are out of line with peers and 
subordinates because of age, competence, ethnic 


background, education or just plain flat personality. 
Finally, there’s the power specialist who is admired 
by social regulars but no one else because of a 
tendency to buck authority. 

Yet, Project Management Handbook is useful even if 
it is not comprehensive, up to date and consistent. 
The "Behavioral Dimensions of Project 
Management” section has some good material on 
leadership, worthy of reflection and analysis. Each of 
the eight sections starts with a brief description of 
each article, and the difTerent points of view may be 
of more value than a single author attempting to 
cover the whole field, from conceptual phase to 
phasing-out and evaluation. --WML 

Project Manager Game , by Nancy Bingham, 1988. 
Ames Research Center, MofTett Field, CA. 

An employee at Ames Research Center has devised a 
game that should put Monopoly out of business, at 
least among project managers in NASA. 

Nancy Bingham’s Project Manager Game is in 
production at the Ames Graphics Department, with 
about 50 boards and sets of gamecards set for the first 
of what may become many press runs. 

According to the draft rules, the boardgame consists 
of bonus and penalty points in three categories, 
technical quality, cost and schedule. The objectives 
are "to perform your job as project manager to deliver 
the best technical, high-quality product at the least 
cost and minimum development time.” 

Like most boardgames, this one is driven by a pawn 
moving forward at the roll of a single die. The board 
itself is divided into four "phases”: requirements 

definition, project planning, project performance and 
project closeout. 

Each phase consists of spaces along the board, some 
of them labeled "crisis” and "zap.” The player 
landing on a crisis space draws a crisis card which 
presents a problem and three possible alternatives, 
some of which will cost points. For example, heres 
one from the first phase: 

Project funding is cut by 25% after requirements are 
finalized. 

A) descope project to meet budget. 

B) advocate additional funding. 

C) assume budget risk (buy dn). 
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If you select "A”, you lose 15 points in technical 
quality (TQ), 10 points in cost (C), and 10 points in 
schedule (S). Choose "B” and you lose 15 points in C 
and 15 points in S. If you chose ''C”, you lose 15 
points in TQ, 20 points in C, and 10 points in S. 

The other set of cards, zap cards, may be given to 
another player at certain times. Here's one from the 
project planning phase: 

All internal manpower is already assigned to key 
projects. Youll have to hire to fill your project's 
positions. Subtract 15 points for TQ, 10 points for C 
and 20 points for S. 

The idea behind zap cards is connected to the "zero 
sum game” often played for real in companies. In 
other words, your requirements for resources will 
affect the other projects going on in the company at 
the same time. 

Gradually, each player advances along the board, 
facing crises or getting zapped until bonus points are 
awarded for reaching the next phase. 

But a project manager's career is not that simple or 
worry-free. At each of the four progress spaces, the 
player must draw both a crisis card and a zap card. 
The zinger, however, is at the end of the game. Most 
games end with the winner as the person with the 
most points. Ms. Bingham notes: "Other 

considerations may disqualify the winner with the 
most points. These will be explained at the end of the 
game.” Sound familiar?— WML 


In Brief 

Managing Projects in Organizations , by J. Davidson 
Frame, 1987. Jossey-Bass Publishers, San Francisco. 

This 240-page book is written primarily for those 
involved in information systems projects, claiming 
that the same project management techniques that 
yield products can be applied to information systems 
as well. Frame recommends a focus on people, 
though, not techniques, recommending the Myers- 
Briggs Type Indicator. In a requirements section, he 
claims that most projects are started too soon. In a 
third section, on tools and techniques, Frame notes 


that the cost of administering projects can be half or 
more of total costs, so the project should be measured 
from all angles. 

Out of the Crisis , by W. Edwards Deming, 1988. MIT 
Press, Cambridge, Mass. 

The guru of Japanese management, Deming, now 88, 
issues a new edition of his classic study in his 
twilight years. Foremost among the new corporate 
folklore principles here is his 85-15 Rule: production 
problems are the result of workers only 15 percent of 
the time; the rest is caused by management. In direct 
opposition to "search for excellence” theories, he is 
appalled at MBWA, management by wandering 
about, because most managers do not ask the right 
questions nor stop walking long enough to get the 
right answers. He deplores the whole idea of 
management-by-objectives, and he opposes 
performance appraisals and quality circles, the latter 
beyond management responsibility. What does he 
like? Dedication to quality which is contagious, 
spreading to an increase in productivity, a decrease 
of cost, satisfied customers and happy workers. 

Management: A Bibliography for NASA Managers 
(NASA SP-7500) Scientific and Technical 
Information Division, annual. This is a selection of 
annotated references to unclassified reports and 
journal articles that are introduced into the NASA 
scientific and technical information system. Items 
are selected on the basis of their usefulness to NASA 
mangers, and they are grouped into 20 categories 
ranging from Human Factors and Personnel Issues to 
Management Theory and Techniques. They are 
indexed six ways. Available from the National 
Technical Information Service. 

NASA/SCAN: Selected Current Aerospace Notices. 
Scientific and Technical Information Division, 
semimonthly. SCAN is a current awareness 
publication covering a full spectrum of aeronautic 
and aerospace information, segmented into about 75 
categories, including management. Each SCAN 
topic resembles a newsletter and can be customized 
for an individual. SCAN topics are available free to 
NASA employees, university libraries, and 
contractors registered with the NASA Scientific and 
Technical Information Facility. Others may 
subscribe at a nominal charge. 
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PREPARATION OF THE REPORT DOCUMENTATION PAGE 


The last page of a report facing the third cover is the Report Documentation Page, RDP. Information presented on this 
page is used in announcing and cataloging reports as well as preparing the cover and title page. Thus it is important 
that the information be correct. Instructions for filling in each block of the form are as follows: 


Block 1. Report No. NASA report series number, if 
preassigned. 

Block 2. Government Accession No. Leave blank. 

Block 3. Recipient's Catalog No. Reserved for use by each 
report recipient. 

Block 4. Title and Subtitle. Typed in caps and lower case 
with dash or period separating subtitle from title. 

Block 5. Report Date. Approximate month and year the 
report will be published. 

Block 6. Performing Organization Code. Leave blank. 

Block 7. Author(s) . Provide full names exactly as they are 
to appear on the title page. If applicable, the word editor 
should follow a name. 

Block 8. Performing Organization Report No. NASA in- 
stallation report control number and, if desired, the non- 
NASA performing organization report control number. 

Block 9. Performing Organization Name and Address. Pro- 
vide affiliation (NASA program office, NASA installation, 
or contractor name) of authors. 

Block 10. Work Unit No. Provide Research and 
Technology Objectives and Plans (RTOP) number. 

Block 1 1 . Contract or Grant No. Provide when applicable. 

Block 12. Sponsoring Agency Name and Address. 
National Aeronautics and Space Administration, Washing- 
ton, D.C. 20546-0001. If contractor report, add NASA in- 
stallation or HQ program office. 

Block 13. Type of Report and Period Covered. NASA for- 
mal report series; for Contractor Report also list type (in- 
terim, final) and period covered when applicable. 

Block 14. Sponsoring Agency Code. Leave blank. 

Block 15. Supplementary Notes. Information not included 
elsewhere: affiliation of authors if additional space is re- 


quired for block 9, notice of work sponsored by another 
agency, monitor of contract, information about sup- 
plements (film, data tapes, etc.), meeting site and date for 
presented papers, journal to which an article has been sub- 
mitted, note of a report made from a thesis, appendix by 
author other than shown in block 7. 

Block 16. Abstract. The abstract should be Informative 
rather than descriptive and should state the objectives of 
the investigation, the methods employed (e.g., simulation, 
experiment, or remote sensing), the results obtained, and 
the conclusions reached. 

Block 17. Key Words. Identifying words or phrases to be 
used in cataloging the report. 

Block 18. Distribution Statement. Indicate whether report 
is available to public or not. If not to be controlled, use 
"Unclassified-Unlimited.” If controlled availability is re- 
quired, list the category approved on the Document 
Availability Authorization Form (see NHB 2200.2, Form 
FF427). Also specify subject category (see 'Table of Con- 
tents” in a current issue of STAR ), In which report is to 
be distributed. 

Block 19. Security Classification (of this report). 
Self-explanatory. 

Block 20. Security Classification (of this page). 
Self-explanatory. 

Block 21 . No. of Pages. Count front matter pages begin- 
ning with iii, text pages including Internal blank pages, and 
the RDP, but not the title page or the back of the title page. 

Block 22. Price Code. If block 18 shows "Unclassified- 
Unlimited,” provide the NTIS price code (see "NTtS Price 
Schedules” in a current issue of STAR ) and at the bot- 
tom of the form add either "For sale by the National 
Technical Information Service, Springfield, VA 
22161-2171” or "For sale by the Superintendent of 
Documents, U.S. Government Printing Office, 
Washington, DC 20402-0001,” whichever is appropriate. 



